subject:"\[HACKERS\] Adding support for SE\-Linux security"

Tom,

* Tom Lane (t...@sss.pgh.pa.us) wrote:
It's been perfectly clear since day one, and was reiterated as recently
as today
http://archives.postgresql.org/message-id/4b21757e.7090...@2ndquadrant.com
that what the security community wants is row-level security.

Yes, they do want row-level security. That being said, KaiGai, and
others, have pointed out time and time over again that SEPG without
row-level security is still useful. Additionally, I see absolutely no
way that PG would accept a full SEPG+PGACE+row-level security, etc,
patch in as one whole patch, ever. I have extreme doubt it would even
be something done over one *release*.

That all aside, for the moment, I feel that we should begin a
'two-prong' attack here. First, continue down the path that I've
started to lay out for SEPG. Second, let's hash out a design for
row-level security using the existing PG security model; ideally
using the best features and design decisions of the numerous row-level
security systems already implemented by the major SQL vendors today.

I'll start a new thread on this specific topic to hopefully pull out
anyone who's focus is more on that than on SEPG.

The
proposals to make SEPostgres drive regular SQL permissions never came
out of anyone from that side, they were proposed by PG people looking
for a manageable first step.

I do not believe this to be accurate. Josh, were you able to find any
public documentation on Trusted Rubix (is that the right name?)? The
RDBMS security policy hashed out on the SELinux list during the
discussion of Rubix and SEPG certainly included support for table-level
objects, did it not? I expect that the SELinux list contributors would
have pointed out if they didn't feel that was at all valuable.

Perhaps what is at issue is the terminology being used here though, or
the approach to enforment being considered. Part of the discussion at
the BWPUG meeting involved the option for SEPG to be a more-restrictive
only model in it's implementation. Essentially, this means that all
permissions handling is done the same as it is today, except that once
the PG model has decided an action is allowed, SEPG kicks in and does
any additional checking of the action being requested it wants and may
deny it.

At the end of the day, I don't feel that it really changes the
architecture of the code though. Perhaps users of SELinux will always
want that, but the argument we've heard time and time again here is that
this should be a generalized approach that other security managers could
hook into and use. To do that, I feel we first have to start with the
PG model, which *does* care about all the SQL permissions. Let's
extract the various complaints and concerns about SELinux that have been
thrown around this list and instead consider our first client of the
PG modular security framework to be the existing PG SQL permissions
system. If we can agree to that, then it's clear that we can't just
hand-wave the requirement that it be capable of driving the regular SQL
permissions.

Whatever you might believe about the
potential market for SEPostgres, you should divide by about a hundred
as long as it's only an alternate interface to SQL permissions. See
particularly here:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG#Revisiting_row-level_security
Without it, it's questionable whether committing the existing
stripped-down patch really accomplishes anything --- how much
clearer can they be?

Again, let's please address row-level security first at the PG level.
That was recommended previously by many on this list and is clearly a
useful feature which can stand alone in any case.

If you're not prepared to assume that we're going to do row level
security, it's not apparent why we should be embarking on this course
at all. And if you do assume that, I strongly believe that my effort
estimate above is on the optimistic side.

I do assume we're going to do row level security, but I do not feel that
we need to particularly put one in front of the other. I also feel that
SEPG will be valuable even without row-level security. One of the
realms that we discussed at BWPUG for this is PCI compliance. I'm
hopeful Josh will have an opportunity to review the PCI compliance
cheat-sheet that I recall Robert Treat offering and comes to agreement
that SEPG w/o row-level security would greatly improve our ability to
have a PCI compliant system backed with PG.

Thanks,

Stephen

signature.asc
Description: Digital signature

Re: [HACKERS] Adding support for SE-Linux security

On Fri, Dec 11, 2009 at 4:31 AM, Magnus Hagander mag...@hagander.net wrote:
 On Fri, Dec 11, 2009 at 05:45, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 My guess is that a credible SEPostgres offering will require a long-term
 amount of work at least equal to, and very possibly a good deal more
 than, what it took to make a native Windows port.

 The SEPostgres community is surely a lot smaller than the Windows
 community, but I'm not sure whether the effort estimate is accurate or
 not.  If credible includes row-level security, then I think I
 might agree, but right now we're just trying to get off the ground.

 It's been perfectly clear since day one, and was reiterated as recently
 as today
 http://archives.postgresql.org/message-id/4b21757e.7090...@2ndquadrant.com
 that what the security community wants is row-level security.  The

 If that is true, then shouldn't we have an implementation of row level
 security *first*, and then an implementation of selinux hooks that
 work with this row level security feature? Rather than first doing
 selinux hooks, then row level security, which will likely need new
 and/or changed hooks...

 I'm not convinced that row level security is actually that necessary
 (though it's a nice feature, with or without selinux), but if it is,
 it seems we are approaching the problem from the wrong direction.

I don't think there's a correct ordering to SE-PostgreSQL and
row-level security.  They're better together, but I don't think either
has to be done first.  If we were going to pick one to do first, I'd
pick SE-PostgreSQL.  Row-level security is going to be a @$#! of a
project if we want it done right (and we do).

...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] Adding support for SE-Linux security

2009/12/11 KaiGai Kohei kai...@ak.jp.nec.com:
 It tried to provide a set of comprehensive entry points to replace existing
 PG checks at once.
 However, the SE-PgSQL/Lite patch covers accesses on only database, schema,
 tables and columns. Is it necessary to be comprehensive from the beginning?
 It might be too aggressive changes at once.

 Frankly, I hesitate to salvage the patch once rejected, as is.

 If we implement a set of security hooks, It seems to me the following approach
 is reasonable:

 * It does not touch the existing PG default checks.
  The purpose of security hooks are to host enhanced security features.

 * It does not deploy hooks on which no security provider is now proposed.
  It is important to reduce unnecessary changeset.

I think that we should try to move the PG default checks inside the
hook functions.  If we can't do that cleanly, it's a good sign that
the hook functions are not correctly placed to enforce arbitrary
security policy.  Furthermore, it defeats what I think would be a good
side goal here, which is to better modularize the existing code.

What I would suggest is that you develop a version of that patch that
is stripped down to apply to only a single object type (databases?
tables and columns - these might have to be together??) and which
addresses Tom's criticisms from the last time around, and post that
(on a new thread) for discussion.  That will be much easier to review
(and I will personally commit to reviewing it) but should allow us to
flush out some of the design issues.  If we can get agreement on that
as a concept patch, we can move on to talking about which object types
should be included in a committable version of that patch.

...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] Adding support for SE-Linux security

2009-12-11 Thread Joshua Brindle

Stephen Frost wrote:

Tom,

snip

The
proposals to make SEPostgres drive regular SQL permissions never came
out of anyone from that side, they were proposed by PG people looking
for a manageable first step.

Trusted RUBIX does use the same SELinux object classes and permissions
that were originally added to the policy to support SEPostgreSQL. You
can look at
http://rubix.com/downloads/documentation/RX_SELinux_Guide_6_0_R4.pdf
and see how they use SELinux in their RDBMS. Pay particular attention to
page 15 where they are saying which object classes and permissions they
are using. They even implement row level security (the db_tuple object
class)

Again, let's please address row-level security first at the PG level.
That was recommended previously by many on this list and is clearly a
useful feature which can stand alone in any case.

Thanks,

Stephen

--
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] Adding support for SE-Linux security

2009-12-11 Thread Stephen Smalley

On Fri, 2009-12-11 at 09:20 -0500, Robert Haas wrote:
 On Fri, Dec 11, 2009 at 4:31 AM, Magnus Hagander mag...@hagander.net wrote:
  On Fri, Dec 11, 2009 at 05:45, Tom Lane t...@sss.pgh.pa.us wrote:
  Robert Haas robertmh...@gmail.com writes:
  On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
  My guess is that a credible SEPostgres offering will require a long-term
  amount of work at least equal to, and very possibly a good deal more
  than, what it took to make a native Windows port.
 
  The SEPostgres community is surely a lot smaller than the Windows
  community, but I'm not sure whether the effort estimate is accurate or
  not.  If credible includes row-level security, then I think I
  might agree, but right now we're just trying to get off the ground.
 
  It's been perfectly clear since day one, and was reiterated as recently
  as today
  http://archives.postgresql.org/message-id/4b21757e.7090...@2ndquadrant.com
  that what the security community wants is row-level security.  The
 
  If that is true, then shouldn't we have an implementation of row level
  security *first*, and then an implementation of selinux hooks that
  work with this row level security feature? Rather than first doing
  selinux hooks, then row level security, which will likely need new
  and/or changed hooks...
 
  I'm not convinced that row level security is actually that necessary
  (though it's a nice feature, with or without selinux), but if it is,
  it seems we are approaching the problem from the wrong direction.
 
 I don't think there's a correct ordering to SE-PostgreSQL and
 row-level security.  They're better together, but I don't think either
 has to be done first.  If we were going to pick one to do first, I'd
 pick SE-PostgreSQL.  Row-level security is going to be a @$#! of a
 project if we want it done right (and we do).

I'm not sure it is a strong analogy, but as an example, in the case of
Linux, we started by integrating support for a base set of access
controls over directories and files, and only later introduced support
for multi-level/polyinstantiated directories by building upon Linux's
per-process filesystem namespace construct.  The base set of access
controls for directories and files were certainly useful on their own
even before we had the support for polyinstantiated directories.

In any event, I would agree that support for applying MAC over the
database objects and operations is useful even without row-level
security, although ultimately we would like both.

-- 
Stephen Smalley
National Security Agency


-- 
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] Adding support for SE-Linux security

On Fri, 2009-12-11 at 09:32 -0500, Robert Haas wrote:
 2009/12/11 KaiGai Kohei kai...@ak.jp.nec.com:
  It tried to provide a set of comprehensive entry points to replace existing
  PG checks at once.
  However, the SE-PgSQL/Lite patch covers accesses on only database, schema,
  tables and columns. Is it necessary to be comprehensive from the beginning?
  It might be too aggressive changes at once.
 
  Frankly, I hesitate to salvage the patch once rejected, as is.
 
  If we implement a set of security hooks, It seems to me the following 
  approach
  is reasonable:
 
  * It does not touch the existing PG default checks.
   The purpose of security hooks are to host enhanced security features.
 
  * It does not deploy hooks on which no security provider is now proposed.
   It is important to reduce unnecessary changeset.
 
 I think that we should try to move the PG default checks inside the
 hook functions.  If we can't do that cleanly, it's a good sign that
 the hook functions are not correctly placed to enforce arbitrary
 security policy.  Furthermore, it defeats what I think would be a good
 side goal here, which is to better modularize the existing code.

So from the meeting on Wednesday I got the impression that Steve already
did this. However it was rejected because too much information was need
to be passed around. I gathered and I could be wrong but the reason for
this is that instead of developing proper abstractions for the security
code people made use of whatever local stuff was available to them at
that location. With the X-ACE work that Eamon Walsh did he did exactly
what you're saying. He figured out the object model for the X-Server and
created the hook framework. In the merge of the hook framework he also
moved the existing X server security model into the framework. 

 
 What I would suggest is that you develop a version of that patch that
 is stripped down to apply to only a single object type (databases?
 tables and columns - these might have to be together??) and which
 addresses Tom's criticisms from the last time around, and post that
 (on a new thread) for discussion.  That will be much easier to review
 (and I will personally commit to reviewing it) but should allow us to
 flush out some of the design issues.  If we can get agreement on that
 as a concept patch, we can move on to talking about which object types
 should be included in a committable version of that patch.

They may have been said before but what exactly are the design issues?
The main concern I hear is that people are worried that this is an
SELinux specific design. I heard at the meeting on Wednesday that the
Trusted Extensions people looked at the framework and said it meets
their needs as well. If thats the case where does the concept that the
design is SELinux specific stem from? We've asked Casey Schaufler the
developer of another label based MAC system for Linux to look at the
hooks as well and make a statement about their usability.

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] Adding support for SE-Linux security

Magnus,

* Magnus Hagander (mag...@hagander.net) wrote:
 On Fri, Dec 11, 2009 at 05:45, Tom Lane t...@sss.pgh.pa.us wrote:
  It's been perfectly clear since day one, and was reiterated as recently
  as today
  http://archives.postgresql.org/message-id/4b21757e.7090...@2ndquadrant.com
  that what the security community wants is row-level security.  The
 
 If that is true, then shouldn't we have an implementation of row level
 security *first*, and then an implementation of selinux hooks that
 work with this row level security feature? Rather than first doing
 selinux hooks, then row level security, which will likely need new
 and/or changed hooks...

The proposal we're currently grappling with is to pull all the various
checks which are sprinkled through our code into a single area.
Clearly, if that work is done before we implement row-level security,
then the patch for row-level security will just add it's checks in the
security/ area and it'd be then easily picked up by SELinux, etc.

 I'm not convinced that row level security is actually that necessary
 (though it's a nice feature, with or without selinux), but if it is,
 it seems we are approaching the problem from the wrong direction.

It has to be implemented independent of the security/SELinux/etc changes
in any case, based on what was said previously..  So I don't
particularly understand why it matters a great deal which one happens
first.  They're independently useful features, though both are not
nearly as good on their own as when they are combined.  Sorry, I just
don't see this as a cart-before-the-horse case.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Adding support for SE-Linux security

On Fri, 2009-12-11 at 08:56 -0500, Stephen Frost wrote:
[snip...]

 I do assume we're going to do row level security, but I do not feel that
 we need to particularly put one in front of the other.  I also feel that
 SEPG will be valuable even without row-level security.  One of the
 realms that we discussed at BWPUG for this is PCI compliance.  I'm
 hopeful Josh will have an opportunity to review the PCI compliance
 cheat-sheet that I recall Robert Treat offering and comes to agreement
 that SEPG w/o row-level security would greatly improve our ability to
 have a PCI compliant system backed with PG.
 

So I downloaded and read through the PCI DSS document (74 pages is
pretty light compared to NFSv4.1 hehe...) and There are several areas
there where I think strong access controls in the database will not only
fulfill the requirement but provide much stronger guarantees than can be
provided from the application server alone.

The requirements in section 7 can definitely benefit from SEPG. If you
implement these requirements in the application server and in PG access
controls alone there is still an attack vector where a malicious user
manages to steal the credentials for a particular role. With PG-ACE you
can write a security module (although SEPG already allows for this) to
restrict access to the data using the existing role-based access
controls in PG and then apply additional restrictions such as, only this
program may act as this role or access this database. This provides
better guarantees than exist in current PCI compliant implementations
using PG today.

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] Adding support for SE-Linux security

David,

* David P. Quigley (dpqu...@tycho.nsa.gov) wrote:
 So I downloaded and read through the PCI DSS document (74 pages is
 pretty light compared to NFSv4.1 hehe...) and There are several areas
 there where I think strong access controls in the database will not only
 fulfill the requirement but provide much stronger guarantees than can be
 provided from the application server alone.

Thanks for taking a look!  That sounds like excellent news.  My
apologies for attributing the action item to the wrong individual. :)

 The requirements in section 7 can definitely benefit from SEPG. 

I don't mean to be a pain, and we're all busy, but perhaps you could
include a short description of what 'requirements in section 7' are..
It would help keep the mailing list archive coherent, and be simpler for
folks who aren't familiar with PCI to play along.  A link to the
specific PCI DSS document you looked at would be an alternative, tho not
as good as a 'dumbed-down' description. ;)  That would at least avoid
confusion over which document, since I presume there's more than one out
there.

Thanks again for looking over this!  

Treat, you've dealt alot with PCI in your commercial work; could you
comment on this for the benefit of the list?  I don't doubt David in
the least, but it never hurts to have someone as lucky as yourself in
frequent dealings with PCI compliance to provide any additional
insight.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Adding support for SE-Linux security

* David P. Quigley (dpqu...@tycho.nsa.gov) wrote:
 On Fri, 2009-12-11 at 09:32 -0500, Robert Haas wrote:
  I think that we should try to move the PG default checks inside the
  hook functions.  If we can't do that cleanly, it's a good sign that
  the hook functions are not correctly placed to enforce arbitrary
  security policy.  Furthermore, it defeats what I think would be a good
  side goal here, which is to better modularize the existing code.
 
 So from the meeting on Wednesday I got the impression that Steve already
 did this. However it was rejected because too much information was need
 to be passed around.

KaiGai did all the work, but it was my suggestion to go down this
route and I reviewed KaiGai's patch to do it.  The specific
'review/rejection' email is here:
http://archives.postgresql.org/message-id/10495.1255627...@sss.pgh.pa.us

 I gathered and I could be wrong but the reason for
 this is that instead of developing proper abstractions for the security
 code people made use of whatever local stuff was available to them at
 that location.

That's certainly one concern I continue to have, but as I've been
rereading the threads I'm less confident it's a huge problem- the issue
seemed to be more about the single access_control.c knowing about the
entire PG world.

 With the X-ACE work that Eamon Walsh did he did exactly
 what you're saying. He figured out the object model for the X-Server and
 created the hook framework. In the merge of the hook framework he also
 moved the existing X server security model into the framework. 

It's great to hear specific examples of other projects which have gone
through this headache and come out the other side better for it.

  What I would suggest is that you develop a version of that patch that
  is stripped down to apply to only a single object type (databases?
  tables and columns - these might have to be together??) and which
  addresses Tom's criticisms from the last time around, and post that
  (on a new thread) for discussion.  That will be much easier to review
  (and I will personally commit to reviewing it) but should allow us to
  flush out some of the design issues.  If we can get agreement on that
  as a concept patch, we can move on to talking about which object types
  should be included in a committable version of that patch.
 
 They may have been said before but what exactly are the design issues?

Unfortunately, design isn't nearly as well defined a term as one would
hope.  I believe KaiGai's latest suggestion (which is probably what his
original PGACE implementation was, but I'm going to avoid looking, the
community has enough egg on it's face already wrt this :/) is a good
approach, along with splitting the huge access_control.c file into
per-object pieces.  That's a design change, tho perhaps not the kind of
one others who have commented on the design were thinking about when
they made those statements.

Basically, there's the design of the code layout and how each piece
knows about the other pieces (through header files, etc), and then
there's the design of the function calls/ABI and actual code paths
which are taken when the code is executed (which doesn't particularly
care how the code is laid out in the source tree).  I feel like the
design issues raised have been more about the former and less about
the latter.

 The main concern I hear is that people are worried that this is an
 SELinux specific design. I heard at the meeting on Wednesday that the
 Trusted Extensions people looked at the framework and said it meets
 their needs as well. If thats the case where does the concept that the
 design is SELinux specific stem from? We've asked Casey Schaufler the
 developer of another label based MAC system for Linux to look at the
 hooks as well and make a statement about their usability.

Hope I didn't steal your thunder wrt Casey!  Thanks again.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Adding support for SE-Linux security

On Fri, Dec 11, 2009 at 10:07 AM, David P. Quigley
dpqu...@tycho.nsa.gov wrote:
 On Fri, 2009-12-11 at 09:32 -0500, Robert Haas wrote:
 2009/12/11 KaiGai Kohei kai...@ak.jp.nec.com:
  It tried to provide a set of comprehensive entry points to replace existing
  PG checks at once.
  However, the SE-PgSQL/Lite patch covers accesses on only database, schema,
  tables and columns. Is it necessary to be comprehensive from the beginning?
  It might be too aggressive changes at once.
 
  Frankly, I hesitate to salvage the patch once rejected, as is.
 
  If we implement a set of security hooks, It seems to me the following 
  approach
  is reasonable:
 
  * It does not touch the existing PG default checks.
   The purpose of security hooks are to host enhanced security features.
 
  * It does not deploy hooks on which no security provider is now proposed.
   It is important to reduce unnecessary changeset.

 I think that we should try to move the PG default checks inside the
 hook functions.  If we can't do that cleanly, it's a good sign that
 the hook functions are not correctly placed to enforce arbitrary
 security policy.  Furthermore, it defeats what I think would be a good
 side goal here, which is to better modularize the existing code.

 So from the meeting on Wednesday I got the impression that Steve already
 did this. However it was rejected because too much information was need
 to be passed around.

I am not sure who Steve is or which patch you're talking about, but
suffice it to say that I think the problem you are articulating here
is exactly the one we need to get out from under.  I don't know how to
do that yet and...

 They may have been said before but what exactly are the design issues?

...that's the design issue I think we need to surmount.  I think it
will be easier to talk through that with a mini-patch that only
affects one object type.

I'll stop here because I see that Stephen Frost has just sent an
insightful email on this topic as well.  Hmm, maybe that's the Steve
you were referring to.

...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] Adding support for SE-Linux security

* Robert Haas (robertmh...@gmail.com) wrote:
 I'll stop here because I see that Stephen Frost has just sent an
 insightful email on this topic as well.  Hmm, maybe that's the Steve
 you were referring to.

I have doubts- but then I don't ever see my comments as insightful for
some reason. ;)

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Adding support for SE-Linux security

On Fri, Dec 11, 2009 at 10:07 AM, David P. Quigley
dpqu...@tycho.nsa.gov wrote:
 The main concern I hear is that people are worried that this is an
 SELinux specific design. I heard at the meeting on Wednesday that the
 Trusted Extensions people looked at the framework and said it meets
 their needs as well. If thats the case where does the concept that the
 design is SELinux specific stem from? We've asked Casey Schaufler the
 developer of another label based MAC system for Linux to look at the
 hooks as well and make a statement about their usability.

OK, on second thought I want to address this a little more, since some
of these concerns came from me.  SE-Linux-specific may be the wrong
way to say it.  There's an old saying that goes something like: if a
function has 10 parameters, it has 11 parameters.  In other words, if
you're passing too much information across a supposed abstraction
boundary, it's not really an abstraction boundary at all.

If we design a security abstraction layer, the interfaces need to
really be abstraction boundaries.  Passing the table OID and then also
the tablespace OID because PG DAC needs that to make its access
control decision is crap.  As soon as some other security model comes
along you will need to add additional arguments for all of the things
that the new security model cares about, and when a third security
model comes along you will need to pass those things now too.  If
we're doing that sort of thing, we might as well leave the entire
jumble of spaghetti code in its original location so that at least you
don't have to flip back and forth between two different source files.
And if we're going to do that, we might as well quit now because our
heads will explode (Tom's first).

I actually have an idea how to solve the problem in this particular
case, but I'm reluctant to say what it is because I'm not sure if I'm
right, and at any rate *I don't want to write this patch*.  I may
review it and if it's good I may commit it (or more likely a more
extensive version of it after we have agreement on the basic
principles) but I don't to want to write it or do substantial cleanup
of it.  I have my own list of things to work on and I presently have
no reason to put this on that list.  As a community, I think that at
times we have a tendency to say well, the committer is just going to
rewrite this anyway, so it doesn't really matter what we do.  As far
as I am concerned that is flat false.  I do not want to rewrite your
patch.  I want to look at your patch, convince myself that it is
correct, and commit it.  That won't always happen, and I'm certainly
willing to do more than that especially in cases where it's a feature
that I really care about, but AFAIAC the initiative is with the patch
author to provide something committable, NOT with the committer to fix
what the patch author did wrong.  I realize that's subjective at
times, and I'm going to make my best effort not to be a jerk about it,
but given that there are only so many hours in the day (and not all of
the can be spent on PostgreSQL) I think that's the goal we need to
shoot for.

...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] Adding support for SE-Linux security

On Fri, 2009-12-11 at 11:28 -0500, Stephen Frost wrote:
[snip...]
  The main concern I hear is that people are worried that this is an
  SELinux specific design. I heard at the meeting on Wednesday that the
  Trusted Extensions people looked at the framework and said it meets
  their needs as well. If thats the case where does the concept that the
  design is SELinux specific stem from? We've asked Casey Schaufler the
  developer of another label based MAC system for Linux to look at the
  hooks as well and make a statement about their usability.
 
 Hope I didn't steal your thunder wrt Casey!  Thanks again.

So we contacted Casey about another MAC model for PG using PG-ACE and he
got back to us with these reponses.

Josh Brindle (JB): So my question is, does smack have a facility
for userspace object managers?

Casey Schaufler (cs): Yes. The smack-util package includes a
small library which supports a user space version of the kernel
smackaccess() function. You pass it the subject label, object
label, and desired access and it returns a yes/no answer based
on what it reads from /smack/load.

So this answers our questions on whether or not SMACK has the faculties
to act as the security decision engine for PG.


JB: If so, I want to make the argument that doing a smack
integration using the pgace abstraction layer would not only
work but be fairly easy.

CS: Looking at some of the documentation I think that you can
safely make that argument. The security_label column would just
be the Smack label. The rules can be enforced by the user space
smackaccess(). System rows, whatever that might be, could get
the floor (_) label.

Casey mentions the row level access control in here but its safe to say
we've broken row based access control into a followup
discussion/project.

JB: All the sepgsql docs and code are up at
http://code.google.com/p/sepgsql/ and I'd like to get your
feedback before I start making claims...

CS: I can't see how it would take more than about a day if pgace
does what it looks like it should.

This seems to be a favorable assesment of the pgace framework's ability
to be used by something other than SELinux. So Casey's Smack module plus
the Sun guys saying it is usable by their legacy TSOL or TX code would
lend credence to the idea that pgace is bringing to the table. It may be
possible that you're not happy with certain aspects of the
implementation but the objects and permissions listed in pgace are
definitely ones that are worth mediating.

Dave

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] Adding support for SE-Linux security

On Fri, 2009-12-11 at 11:16 -0500, Stephen Frost wrote:
 David,
 
 * David P. Quigley (dpqu...@tycho.nsa.gov) wrote:
  So I downloaded and read through the PCI DSS document (74 pages is
  pretty light compared to NFSv4.1 hehe...) and There are several areas
  there where I think strong access controls in the database will not only
  fulfill the requirement but provide much stronger guarantees than can be
  provided from the application server alone.
 
 Thanks for taking a look!  That sounds like excellent news.  My
 apologies for attributing the action item to the wrong individual. :)

Nahh you attributed it to the correct person I just got a little bored
yesterday and poked my nose into it :)

 
  The requirements in section 7 can definitely benefit from SEPG. 
 
 I don't mean to be a pain, and we're all busy, but perhaps you could
 include a short description of what 'requirements in section 7' are..
 It would help keep the mailing list archive coherent, and be simpler for
 folks who aren't familiar with PCI to play along.  A link to the
 specific PCI DSS document you looked at would be an alternative, tho not
 as good as a 'dumbed-down' description. ;)  That would at least avoid
 confusion over which document, since I presume there's more than one out
 there.

So the document I read is linked below [1]. Requirement 7 falls under
Implement Strong Access Control Measures. The two main requirements
under requirement 7 seem to be limit access to system components and
card holder data to only those individuals whose job requires such
access and Establish an access control system for systems components
with multiple users that restricts access based
on a user’s need to know, and is set to “deny all” unless specifically
allowed.

The major flaw with this system is that stolen credentials allow you to
completely bypass the logic for this in the application layer. If the
person manages to get the login and password for an account on the
database it doesn't matter what their authenticated use is because the
logic to prevent accountant bob from cutting his own payroll check is in
the application layer. 

The way that MAC controls can strengthen the protections by making sure
that only certain components can perform certain actions. If you want to
make sure that only the accounting application can mess with that data
regardless of whether you have the database credentials or not then you
can do that. You can write policy for SEPG to say only programs with
this label can perform these actions on the database. Only applications
labeled with the accounting_tool label can modify the table labeled
accounting_data. This way if the system is compromised and someone
manages to get the username and password for the database account/role
that you were protecting the table with since the request isn't coming
from a process labeled accounting_tool the database will deny those
accesses. 

This is why I mean by adding stronger protections. This way you've
minimized the amount of code that you have to accredit for compliance in
your application server.

[1]
https://www.pcisecuritystandards.org/security_standards/download.html?id=pci_dss_v1-2.pdf
 
 Thanks again for looking over this!  
 
 Treat, you've dealt alot with PCI in your commercial work; could you
 comment on this for the benefit of the list?  I don't doubt David in
 the least, but it never hurts to have someone as lucky as yourself in
 frequent dealings with PCI compliance to provide any additional
 insight.

It is definitely good to have a second opinion on this since I've just
only started reading the PCI compliance documents. I'm definitely not an
expert in PCI compliance but from what I've read there are definite
benefits for using SEPG or PG-ACE with a special security module in
making much stronger guarantees about who and what can touch the card
data.

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] Adding support for SE-Linux security

On Fri, 2009-12-11 at 11:30 -0500, Robert Haas wrote:
[snip...]
 
 I'll stop here because I see that Stephen Frost has just sent an
 insightful email on this topic as well.  Hmm, maybe that's the Steve
 you were referring to.
 
 ...Robert
 

Yea I never asked Stephen if he goes by Stephen or Steve when I met him
on Wednesday. I guess calling him Steve is me being a bit
presumptuous :)


-- 
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] Adding support for SE-Linux security

Robert,

* Robert Haas (robertmh...@gmail.com) wrote:
 I actually have an idea how to solve the problem in this particular
 case, but I'm reluctant to say what it is because I'm not sure if I'm
 right, and at any rate *I don't want to write this patch*.  

As far as crap goes, I'd have to put this at the top.  If you're not
willing to share ideas, then I may have to reconsider my personal
feeling on if you should be a committer or not.  No one is asking you to
write the patch.  We all know that we can be wrong (I tend to be more
wrong than most), and we all hate to jerk people around, but I feel
it's far worse to self-censor discussion on ideas.

It's also about the worst form of rock-management that I think I could
come up with in an open source community.  If you don't share your idea,
yet you feel that it's right, and see nothing to dissuade you from
that position (after all, we can't present an argument for or against it
if we don't know what it is), then I find it likely that you're going to
constantly be comparing patches presented to the ideal one in your head
based on your idea and we'd never get there.

If you're not willing to discuss your idea, then I would ask that
you not be involved in either this discussion or review of the patch.

Rock-management, for those not familiar with the term, is essentially
asking I need a rock, and then, when presented with a rock saying
sorry, that's not the rock I wanted.  This doesn't provide any insight
into what kind of rock you're looking for.

Rest of the I don't want to write it whine omitted.  No one's asking
you to.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Adding support for SE-Linux security

All,

* Robert Haas (robertmh...@gmail.com) wrote:
 If we design a security abstraction layer, the interfaces need to
 really be abstraction boundaries.  Passing the table OID and then also
 the tablespace OID because PG DAC needs that to make its access
 control decision is crap.  

Now, to address the small useful bit of this mail- I tend to agree with
this.  I'm not convinced there's an alternative, but I'd like to throw
out a couple of my ideas on how it could be addressed.  I'd like to
solicit for feedback on these.

First off, we have alot of the information available from the catalog.
Basically, given an OID, we should be able to find out the other
information associated with that OID (such as what kind of object it is,
what tablespace it resides in, etc).  OID isn't sufficient, however, as
we know from the dependency system.  To address this, we would need OID
and SubOID.  Now, any information which we can derive from those should
not be included in the API.  To be honest, I don't think we've actually
been all that bad about this, but I'll reserve any definitive answer
until I've gone back through the API we have specifically thinking about
this issue.  On further thought, I'm probably wrong and should have
caught this during my review.  Sorry.

Second, the information we *don't* have from above is generally
information about what the requesting action is.  For example, when
changing ownership of an object, we can't possibly use introspection to
find out the role which is on the receiving end, since at that time
we've just learned it from the parser.  Now, we might build an entire
new object, pass the result of this action OID to the security system
and ask it can we change OID X into OID Y?, but I don't particularly
like it.  We really don't want to do any *changes* to things until after
we've determined the permissions allow for it, and I'm not sure how to
get around that without building an independent introspection system for
what might be.  Perhaps we're comfortable enough saying we'll just
rollback the command if it turns out to have not been allowed but I
just don't like it.  Feels like a higher risk solution to me.

I don't see a way to get around the second piece since what information
is needed about the action is typically action-specific.  Perhaps we
could have an 'action-ID' (uh, we have an ID per command already, no?
Probably doesn't fit the mold close enough though), and then a way to
query information about what is this action trying to do?.  Doesn't
seem likely to be very clean though.

Other thoughts?

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Adding support for SE-Linux security

On Fri, Dec 11, 2009 at 1:52 PM, Stephen Frost sfr...@snowman.net wrote:
 * Robert Haas (robertmh...@gmail.com) wrote:
 I actually have an idea how to solve the problem in this particular
 case, but I'm reluctant to say what it is because I'm not sure if I'm
 right, and at any rate *I don't want to write this patch*.

 As far as crap goes, I'd have to put this at the top.  If you're not
 willing to share ideas, then I may have to reconsider my personal
 feeling on if you should be a committer or not.  No one is asking you to
 write the patch.  We all know that we can be wrong (I tend to be more
 wrong than most), and we all hate to jerk people around, but I feel
 it's far worse to self-censor discussion on ideas.

OK, it's clear that I've handled this badly.  Sorry.  My fear (however
unjustified) was that someone would go and rewrite the patch based on
an opinion that I express whether they agree with it or not.  I don't
know the right way to do this and I'm sorry to have given you the
impression that I think I do and am hiding the ball.

So with that said, the idea I had was to try to pass around
pre-existing data structures related to the objects on which access
control decisions are being made, rather than Oids.  It's pretty clear
that you're never going to be able to make an access control decision
just based on the Oid, but the Relation descriptor or pg_something
HeapTuple might be enough - or at least whatever else you need is
likely something you would have had to look up anyway, even without
the interface layer.  I don't know if that makes sense or actually
works, but you could give it a try.

 It's also about the worst form of rock-management that I think I could
 come up with in an open source community.  If you don't share your idea,
 yet you feel that it's right, and see nothing to dissuade you from
 that position (after all, we can't present an argument for or against it
 if we don't know what it is), then I find it likely that you're going to
 constantly be comparing patches presented to the ideal one in your head
 based on your idea and we'd never get there.

It's a little unfortunate that we're arguing about this because that's
exactly what I'm reacting AGAINST, and emphatically not when I intend
to do.  I think this is the first time in my adult life I've been
criticized for being too UN-willing to share my opinions, but I guess
there's a first time for everything.  Again, sorry for handling this
badly.  I just feel like the discussions that we've had so far have
been very much in the dynamic of throw some code over the wall and see
if the committer likes it... looks like no, let's go back around and
try again.  It does have a bit of a rock management feel to it and I
really want to see if we can find a way to break that cycle.

...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] Adding support for SE-Linux security

David,

* David P. Quigley (dpqu...@tycho.nsa.gov) wrote:
 So the document I read is linked below [1].

Great, thanks again.

[agree with all the rest]

 It is definitely good to have a second opinion on this since I've just
 only started reading the PCI compliance documents. I'm definitely not an
 expert in PCI compliance but from what I've read there are definite
 benefits for using SEPG or PG-ACE with a special security module in
 making much stronger guarantees about who and what can touch the card
 data.

Indeed.  The other nice piece about getting the opinion of Treat (or
others who have to deal with PCI) is that while the PCI documentation
says what you're supposed to do, the PCI folks also have auditing
requirments (as in, a third-party vendor has to audit your system, and
there are required scans and scanning tools, etc) which don't always
marry up to what they say they require.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Adding support for SE-Linux security

* David P. Quigley (dpqu...@tycho.nsa.gov) wrote:
 Yea I never asked Stephen if he goes by Stephen or Steve when I met him
 on Wednesday. I guess calling him Steve is me being a bit
 presumptuous :)

Oh, either is fine, tho people will probably follow a bit better if you
say Stephen.  As a reminder- KaiGai's the one who did all the actual
code, I just tried to steer him in a direction I thought made sense to
make it easier to get core to accept it, and reviewed the results of his
work.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Adding support for SE-Linux security

On Fri, Dec 11, 2009 at 2:11 PM, Stephen Frost sfr...@snowman.net wrote:
 Second, the information we *don't* have from above is generally
 information about what the requesting action is.  For example, when
 changing ownership of an object, we can't possibly use introspection to
 find out the role which is on the receiving end, since at that time
 we've just learned it from the parser.

I'm not sure that I follow what you're saying here.  I think maybe it
would help to discuss a concrete example, which is why I proposed a
concept patch.  Or perhaps you'd like just to pick out a specific case
to discuss.

 Now, we might build an entire
 new object, pass the result of this action OID to the security system
 and ask it can we change OID X into OID Y?, but I don't particularly
 like it.  We really don't want to do any *changes* to things until after
 we've determined the permissions allow for it, and I'm not sure how to
 get around that without building an independent introspection system for
 what might be.  Perhaps we're comfortable enough saying we'll just
 rollback the command if it turns out to have not been allowed but I
 just don't like it.  Feels like a higher risk solution to me.

Yeah, that seems like a non-starter.

 I don't see a way to get around the second piece since what information
 is needed about the action is typically action-specific.  Perhaps we
 could have an 'action-ID' (uh, we have an ID per command already, no?
 Probably doesn't fit the mold close enough though), and then a way to
 query information about what is this action trying to do?.  Doesn't
 seem likely to be very clean though.

Object creation seems to be one of the tougher cases here.  When
you're altering or dropping an existing object, the decision is likely
to be based (in any system) on the properties of that object.  When
you're creating an object, the decision will of course have to be
based on the properties of something else, but different access
control models might not agree on the value of something else.  It's
not immediately clear to me how to deal with that, but again it's hard
for me to discuss it in the abstract.

...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] Adding support for SE-Linux security

2009-12-11 Thread Stephen Smalley

On Fri, 2009-12-11 at 14:11 -0500, Stephen Frost wrote:
 All,
 
 * Robert Haas (robertmh...@gmail.com) wrote:
  If we design a security abstraction layer, the interfaces need to
  really be abstraction boundaries.  Passing the table OID and then also
  the tablespace OID because PG DAC needs that to make its access
  control decision is crap.  
 
 Now, to address the small useful bit of this mail- I tend to agree with
 this.  I'm not convinced there's an alternative, but I'd like to throw
 out a couple of my ideas on how it could be addressed.  I'd like to
 solicit for feedback on these.
 
 First off, we have alot of the information available from the catalog.
 Basically, given an OID, we should be able to find out the other
 information associated with that OID (such as what kind of object it is,
 what tablespace it resides in, etc).  OID isn't sufficient, however, as
 we know from the dependency system.  To address this, we would need OID
 and SubOID.  Now, any information which we can derive from those should
 not be included in the API.  To be honest, I don't think we've actually
 been all that bad about this, but I'll reserve any definitive answer
 until I've gone back through the API we have specifically thinking about
 this issue.  On further thought, I'm probably wrong and should have
 caught this during my review.  Sorry.
 
 Second, the information we *don't* have from above is generally
 information about what the requesting action is.  For example, when
 changing ownership of an object, we can't possibly use introspection to
 find out the role which is on the receiving end, since at that time
 we've just learned it from the parser.  Now, we might build an entire
 new object, pass the result of this action OID to the security system
 and ask it can we change OID X into OID Y?, but I don't particularly
 like it.  We really don't want to do any *changes* to things until after
 we've determined the permissions allow for it, and I'm not sure how to
 get around that without building an independent introspection system for
 what might be.  Perhaps we're comfortable enough saying we'll just
 rollback the command if it turns out to have not been allowed but I
 just don't like it.  Feels like a higher risk solution to me.
 
 I don't see a way to get around the second piece since what information
 is needed about the action is typically action-specific.  Perhaps we
 could have an 'action-ID' (uh, we have an ID per command already, no?
 Probably doesn't fit the mold close enough though), and then a way to
 query information about what is this action trying to do?.  Doesn't
 seem likely to be very clean though.
 
 Other thoughts?

In the Linux LSM case, we define a separate hook interface for each
logical operation/action, where hook name identifies the
action/operation and the set of arguments to that hook interface are the
complete set of inputs that may be relevant to deciding whether to
permit the operation/action.   These arguments typically include
pointer(s) to one or more object data structures as well as ancillary
arguments (e.g. new owner value if chown).  Reference:
http://www.usenix.org/event/sec02/wright.html
http://lxr.linux.no/#linux+v2.6.32/include/linux/security.h

The XACE framework for the X server is described by:
http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html
Unlike the LSM framework, it passes resource identifiers rather than
direct object pointers.

The FreeBSD MAC framework is described by:
http://www.freebsd.org/doc/en/books/arch-handbook/mac.html
It provides more abstraction than LSM does, at a cost in the overhead of
the framework itself.

-- 
Stephen Smalley
National Security Agency


-- 
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] Adding support for SE-Linux security

* Robert Haas (robertmh...@gmail.com) wrote:
 OK, it's clear that I've handled this badly.  Sorry.  My fear (however
 unjustified) was that someone would go and rewrite the patch based on
 an opinion that I express whether they agree with it or not.

That's always going to be a risk in an open-discussion environment.
Additionally, that's exactly what happened to me last go round- KaiGai
rewrote the patch based on my ideas and suggestions, and the result was
summarairly tossed out by Tom.  Did it suck?  Yes, heavily, and it
frustrated me to the point that I specifically asked to not be the
reviewer for SEPG during the next commitfest.  At the same time,
what KaiGai or others spend time on is up to them (and/or their
employers).

I sincerely hope that even if you suggest an approach down the road
unrelated to this on some other patch you're reviewing, and then you see
the results and say whoah, that's horrible, and should never be
committed, that you understand none of us would want you to commit it.
Sharing your ideas or putting out suggestions isn't a commitment on your
part that you'll commit the results when someone else rights it.  Heck,
I bet you've been down that road on your own projects and come to the
realization at the end of err, bad idea and not committed it.

Allow me to say, my apologies, I feel like I may have over-reacted a bit
for my part as well.

 So with that said, the idea I had was to try to pass around
 pre-existing data structures related to the objects on which access
 control decisions are being made, rather than Oids.  

That thought had crossed my mind as well, but I wasn't convinced that
would actually be seen as a signifigantly different API to just having
the arguments passed inline...  Then again, using structures does
allow you to add to them without having to modify the function
definitions, and would allow David's suggestion of using function
pointers to work, which we do in some other specific cases.  I guess I'm
curious if we (PG) have any particular feeling one way or the other
about function pointers; I just don't recall seeing them used terribly
often and would worry about that they might be passively discouraged?

 It does have a bit of a rock management feel to it and I
 really want to see if we can find a way to break that cycle.

Agreed.  It's been a point of frustration for me, but I've been trying
to work with it so long as we at least get some constructive critisim
back (Tom's review of the patch I reviewed fell into the questionable
category for me on that call, which is what really frustrated me the
most about it).  A cyclic approach is typical in all software
development, it's when information stops flowing about why something
doesn't meet expectations or requirments that progress breaks down.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Adding support for SE-Linux security

* Robert Haas (robertmh...@gmail.com) wrote:
 On Fri, Dec 11, 2009 at 2:11 PM, Stephen Frost sfr...@snowman.net wrote:
  Second, the information we *don't* have from above is generally
  information about what the requesting action is.  For example, when
  changing ownership of an object, we can't possibly use introspection to
  find out the role which is on the receiving end, since at that time
  we've just learned it from the parser.
 
 I'm not sure that I follow what you're saying here.  I think maybe it
 would help to discuss a concrete example, which is why I proposed a
 concept patch.  Or perhaps you'd like just to pick out a specific case
 to discuss.

Hrm, I thought I had given a specific example.  Didn't do a good job of
it, apparently.  Let me try to be a bit more clear:

ALTER TABLE x OWNER TO y;

If given the table OID, there's a ton of information we can then pull
about the table- the tablespace, the owner, the schema, the columns, the
privileges, etc, etc.

What we can't possibly figure out from the OID is the value of y.  Yet,
in the PG security model, the value of y matters!  You have to know what
y is to check if y has 'create' rights on the schema.  If it doesn't
(and the user executing the command isn't the superuser) then the
request (under the PG model) is denied.

Does that help clarify my example case?

 Object creation seems to be one of the tougher cases here.  When
 you're altering or dropping an existing object, the decision is likely
 to be based (in any system) on the properties of that object.  When
 you're creating an object, the decision will of course have to be
 based on the properties of something else, but different access
 control models might not agree on the value of something else.  It's
 not immediately clear to me how to deal with that, but again it's hard
 for me to discuss it in the abstract.

That sounds like a pretty good example to me too, to be honest.  It goes
back to the same issue though- that's information you get from the
command that's trying to be run and isn't available from existing
objects.  Using structures to track this information, allowing the
function arguments to remain identical, is certainly something which can
be done, and probably done with a minimal amount of fuss.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Adding support for SE-Linux security

Stephen (great name!),

* Stephen Smalley (s...@tycho.nsa.gov) wrote:
 Reference:
 http://www.usenix.org/event/sec02/wright.html
 http://lxr.linux.no/#linux+v2.6.32/include/linux/security.h
 
 The XACE framework for the X server is described by:
 http://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html
 
 The FreeBSD MAC framework is described by:
 http://www.freebsd.org/doc/en/books/arch-handbook/mac.html

Thanks for these pointers!  I'm sure KaiGai has probably already done a
review of these, but I'll take a look and would ask others who are
interested to please do the same.  Seeing the different options that
people have gone with (as opposed to just the SELinux/kernel version)
will undoubtably be helpful in deciding the best approach forward.

Thanks again!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Adding support for SE-Linux security

On Fri, Dec 11, 2009 at 3:28 PM, Stephen Frost sfr...@snowman.net wrote:
 I sincerely hope that even if you suggest an approach down the road
 unrelated to this on some other patch you're reviewing, and then you see
 the results and say whoah, that's horrible, and should never be
 committed, that you understand none of us would want you to commit it.

I have to thank you for saying this - unfortunately, I don't think
everyone takes this approach.  As you can probably figure out, my
alleged rock management upthread was actually a poorly executed
attempt to avoid being accused of bait-and-switch.  If I don't tell
you how to write the patch, you can't accuse me of moving the
goalposts (of course I've now discovered the pitfalls of that approach
as well...).

 Sharing your ideas or putting out suggestions isn't a commitment on your
 part that you'll commit the results when someone else rights it.  Heck,
 I bet you've been down that road on your own projects and come to the
 realization at the end of err, bad idea and not committed it.

Well, I haven't been a committer long enough to have gone through that
precise process, but sure, I've tossed out ideas when they don't turn
out to be good.

 So with that said, the idea I had was to try to pass around
 pre-existing data structures related to the objects on which access
 control decisions are being made, rather than Oids.

 That thought had crossed my mind as well, but I wasn't convinced that
 would actually be seen as a signifigantly different API to just having
 the arguments passed inline...

If you'll forgive me for saying so, this is exactly the sort of
thinking that I think is killing us.  Who cares how it will be seen?
Seen by whom?  We shouldn't be writing this code to be seen - we
should be writing it to be good.  If doing this makes a clean, tight
abstraction layer, then it's a good design.  If it doesn't, then it
sucks.  I realize that opinions enter into this at some level, but
let's try to proceed as though there's a technically right answer out
there and bend our best efforts to finding it.

 Then again, using structures does
 allow you to add to them without having to modify the function
 definitions,

Personal opinion time, but I think that without having to modify the
function definitions is a CRITICAL design component.  Furthermore,
adding to them [the structures] shouldn't be something that only
happens when we decide to support a new security model, or we're
little better off than if we just passed a kajillion arguments.
Again, I don't want to overstate my confidence in this point, but it
feels to me like we need to pass PRE-EXISTING data structures that are
already being used for other things and happen to be the right stuff
to enable access control decisions, and to which fields that are
likely to be needed are likely to get added anyway.  But it's
difficult to know whether this approach can be made to work without
trying it, and there are bound to be problem cases that need to be
thought about, and that thinking will be more likely to lead to a good
result if it happens in the community, rather than by KaiGai or any
other single person in isolation.

 and would allow David's suggestion of using function
 pointers to work, which we do in some other specific cases.  I guess I'm
 curious if we (PG) have any particular feeling one way or the other
 about function pointers; I just don't recall seeing them used terribly
 often and would worry about that they might be passively discouraged?

I'm going to vote fairly strongly against inserting function pointers
at the outset.  I think that we should look at the first phase of this
project as an attempt to restructure the code so that the access
control decisions are isolated from the rest of the code.  *If* we can
do that successfully, I think it will represent good progress all on
its own.  Inserting function pointers is something that can be done
later if it turns out to be useful with a very small, self-contained
patch.

 It does have a bit of a rock management feel to it and I
 really want to see if we can find a way to break that cycle.

 Agreed.  It's been a point of frustration for me, but I've been trying
 to work with it so long as we at least get some constructive critisim
 back (Tom's review of the patch I reviewed fell into the questionable
 category for me on that call, which is what really frustrated me the
 most about it).  A cyclic approach is typical in all software
 development, it's when information stops flowing about why something
 doesn't meet expectations or requirments that progress breaks down.

Part of my frustration here is that I don't see a lot of evidence that
anyone is willing to put really tangible resources into this other
than KaiGai and his employer.  I don't want to keep reviewing the same
patches over again just because they keep getting resubmitted with
various modifications.  I am willing to try to be helpful with this
project if that is something that you

Re: [HACKERS] Adding support for SE-Linux security

On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost sfr...@snowman.net wrote:
 Hrm, I thought I had given a specific example.  Didn't do a good job of
 it, apparently.  Let me try to be a bit more clear:

 ALTER TABLE x OWNER TO y;

 If given the table OID, there's a ton of information we can then pull
 about the table- the tablespace, the owner, the schema, the columns, the
 privileges, etc, etc.

 What we can't possibly figure out from the OID is the value of y.  Yet,
 in the PG security model, the value of y matters!  You have to know what
 y is to check if y has 'create' rights on the schema.  If it doesn't
 (and the user executing the command isn't the superuser) then the
 request (under the PG model) is denied.

 Does that help clarify my example case?

That case doesn't seem terribly problematic to me.  It seems clear
that we'll want to pass some information about both x and y.  What is
less clear is exactly what the argument types will be, and the right
answer probably depends somewhat on the structure of the existing
code, which I have not looked at.  What I'm more concerned about is if
the access control decision in this case were based on u for PG DAC, v
for SE-PostgreSQL, and w for Robert Haas's Personal Defensive System.
If that's the case, and our function signature looks like (x,y,u,v,w),
the we should worry.

...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] Adding support for SE-Linux security

* Robert Haas (robertmh...@gmail.com) wrote:
 If I don't tell
 you how to write the patch, you can't accuse me of moving the
 goalposts (of course I've now discovered the pitfalls of that approach
 as well...).

Indeed, we also yell and scream when we don't know which direction the
goalposts are in. ;)

  That thought had crossed my mind as well, but I wasn't convinced that
  would actually be seen as a signifigantly different API to just having
  the arguments passed inline...
 
 If you'll forgive me for saying so, this is exactly the sort of
 thinking that I think is killing us.  Who cares how it will be seen?

erp. mea culpa.  I meant that I didn't think of it as being enough of a
novelty for you to be suggesting-it-but-not-telling-us..  It just kind
of came off as too-obvious, however, the reality is that I didn't
understand your suggestion, see below.

  Then again, using structures does
  allow you to add to them without having to modify the function
  definitions,
 
 Personal opinion time, but I think that without having to modify the
 function definitions is a CRITICAL design component.  Furthermore,
 adding to them [the structures] shouldn't be something that only
 happens when we decide to support a new security model, or we're
 little better off than if we just passed a kajillion arguments.
 Again, I don't want to overstate my confidence in this point, but it
 feels to me like we need to pass PRE-EXISTING data structures that are
 already being used for other things and happen to be the right stuff
 to enable access control decisions, and to which fields that are
 likely to be needed are likely to get added anyway.

Ah, now that makes alot of sense..  Unfortunately, having been involved
in at least some of this code in the past, sadly I don't think we have
such pre-existing data structures for the information that's primairly
at issue here.  Specifically, the data structures we tend to have
pre-existing are the ones that come from the catalog and would fall out
from an OID+SubOID based API.  Sure, we could pass those structures in
instead of using SysCache to pull the data out, but that's not really
how we 'typically' do things in the code base from my experience, and I
don't really see it having alot of advantage.  Using OID+SubOID and
SysCache *will* pick up new things as they're added to the catalogs- for
the information *in* the catalogs.

There are very few data structures outside of the parse tree which
include the information from the parse tree..  And to be honest, the
ones that *are* out there don't typically have the world's best
structure for use by this kind of a framework (thinking back to
specifically what's passed around for column-level privs..).

 But it's
 difficult to know whether this approach can be made to work without
 trying it, and there are bound to be problem cases that need to be
 thought about, and that thinking will be more likely to lead to a good
 result if it happens in the community, rather than by KaiGai or any
 other single person in isolation.

I agree with this- one issue is, unfortunately, an overabundance from
KaiGai of code-writing man-power.  This is an odd situation for this
community, in general, so we're having a hard time coming to grasp with
it.  KaiGai, can you hold off on implementing any of these approaches
until we can hammer down something a bit better for you to work from as
a baseline?  I'll start with Robert's suggestion of a single-object
example case and throw out some example code for people to shoot down of
different approachs.  After a few iterations of that, with comments from
all (KaiGai, you're welcome to comment on it too, of course), we'll turn
you loose on it again to implement fully (if you're still willing to).

Following along that though, as we'd like this to be the design forum,
when you come across problems or issues implementing it, could you come
back to this forum and explain the issue and why it doesn't fit, as soon
as you hit it?  What you tend to do is disappear for a while, then come
back, instead, with a full patch which works, but has places where
you've gone down an unexpected path because you found a case which
wasn't covered, designed a solution for it which kinda fits and then
implemented it immediately.

I feel that's something I've encouraged you to do, unfortunately, and my
apologies for that.  I'm trying to get time from my employer (and my
wife) to dedicate to this, to hopefully avoid that happening in the
future.

 I'm going to vote fairly strongly against inserting function pointers
 at the outset.  I think that we should look at the first phase of this
 project as an attempt to restructure the code so that the access
 control decisions are isolated from the rest of the code.  *If* we can
 do that successfully, I think it will represent good progress all on
 its own.  Inserting function pointers is something that can be done
 later if it turns out to be useful with a very small, self-contained
 patch.

Re: [HACKERS] Adding support for SE-Linux security

* Robert Haas (robertmh...@gmail.com) wrote:
 On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost sfr...@snowman.net wrote:
  Does that help clarify my example case?
 
 That case doesn't seem terribly problematic to me.  It seems clear
 that we'll want to pass some information about both x and y.  What is
 less clear is exactly what the argument types will be, and the right
 answer probably depends somewhat on the structure of the existing
 code, which I have not looked at.

Allow me to assist- y is never in a structure once you're out of the
parser:

ATExecChangeOwner(Oid relationOid, Oid newOwnerId, bool recursing)

I expect you'll find this is more the rule than the exception to alot of
the existing PG security model, because much of it's responsibility is
in what I'll call the DDL (under commands/) aspects.  The DML pieces
(under the executor) are a bit better about this, specifically you could
pass in a RangeTblEntry, exactly how ExecCheckRTEPerms handles it.

Actually, in a fit of barely-contained mirth, it strikes me that PG
really has already done what you're suggesting for the 'hard' part- and
the RangeTblEntry plus ExecCheckRTEPerms is exactly it.  It's all the
*other* checks we do for the PG security model, under commands/, that
are the problem here.  The parts of the code that, to be honest, I think
all us database geeks have historically cared alot less about.

 What I'm more concerned about is if
 the access control decision in this case were based on u for PG DAC, v
 for SE-PostgreSQL, and w for Robert Haas's Personal Defensive System.
 If that's the case, and our function signature looks like (x,y,u,v,w),
 the we should worry.

Right, I understand that.  What I offer in reply is that we focus our
attention on using the OID+SubOID approach, as I'm suggesting, to the
fullest extent possible through that mechanism, and appreciate that the
other arguments passed to the function are derived specifically from the
parser and therefore unlikely to be changed until and unless we change
the base syntax of the command and calling function, at which time we
may have to add arguments to the function signature.  This would
continue at least until we get to the point where we decide that the
caller needs to be changed because it's got a huge function sig, and
move it to something like the structure of the executor and the
equivilant of ExecCheckRTEPerms() would get updated along with it, at
that time.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Adding support for SE-Linux security

2009-12-11 Thread Greg Smith


Stephen Frost wrote:

I agree with this- one issue is, unfortunately, an overabundance from
KaiGai of code-writing man-power.  This is an odd situation for this
community, in general, so we're having a hard time coming to grasp with
it.
There are plenty of parallels to when Zdenek was writing a ton of 
in-place upgrade code faster than anyone else was fully consuming it.  
The do it right or don't do it at all approach of the PG community 
seems particularly hard to reconcile with larger patches from people we 
don't get enough face time with.  It's easy to get deadlocked and not 
have a good way to navigate out when faced with a set of difficult 
decisions and only electronic communications between participants.  
Shoot, you and Robert have spent time doing technical arguments in 
person and we still got a
little rough patch on-list this week out of the debate.  I hate to even 
use this terminology, but these big patches seem to need a project 
manager advocate sometimes:  someone who knows everyone well enough to 
clear these stalled spots, smooth over any personality conflicts, and is 
motivated to intervene because they need the feature.  I see it as a 
sort of scaling problem that might be a recurring one.  It would be nice 
if we could all get better at identifying when it does happen, and 
perhaps find someone to help with planning before we waste so much time 
chasing code that isn't going to be accepted yet again.


--
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] Adding support for SE-Linux security

2009-12-11 Thread Greg Smith

I just did a round of integrating some of the big-picture feedback that 
has shown up here since the meeting into 
http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG , 
mainly supplementing the references in the Works outside of SELinux 
section with the new suggested reading here suggested by Stephen Smalley 
and Joshua Brindle.  I'm trying to keep that a fairly readable intro to 
the controversial parts rather than going deeply technical. 

What I'm not going to try to track is all the low-level implementation 
details that are bouncing around right now, my brain is too full this 
week to cram more about OID trivia into it right now.  That would be a 
good idea for someone to summarize eventually and then throw that onto 
the wiki somewhere else, so that it's easier to remember the context of 
what/why decisions were made.  The way Simon has been keeping an ongoing 
log at http://wiki.postgresql.org/wiki/Hot_Standby shows a reasonable 
way to organize such a thing from a similarly complicated patch.


--
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] Adding support for SE-Linux security

On Fri, Dec 11, 2009 at 5:36 PM, Stephen Frost sfr...@snowman.net wrote:
 * Robert Haas (robertmh...@gmail.com) wrote:
 On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost sfr...@snowman.net wrote:
  Does that help clarify my example case?

 That case doesn't seem terribly problematic to me.  It seems clear
 that we'll want to pass some information about both x and y.  What is
 less clear is exactly what the argument types will be, and the right
 answer probably depends somewhat on the structure of the existing
 code, which I have not looked at.

 Allow me to assist- y is never in a structure once you're out of the
 parser:

Well this is why you're writing the patch and not me.  :-)

 ATExecChangeOwner(Oid relationOid, Oid newOwnerId, bool recursing)

 I expect you'll find this is more the rule than the exception to alot of
 the existing PG security model, because much of it's responsibility is
 in what I'll call the DDL (under commands/) aspects.  The DML pieces
 (under the executor) are a bit better about this, specifically you could
 pass in a RangeTblEntry, exactly how ExecCheckRTEPerms handles it.

 Actually, in a fit of barely-contained mirth, it strikes me that PG
 really has already done what you're suggesting for the 'hard' part- and
 the RangeTblEntry plus ExecCheckRTEPerms is exactly it.  It's all the
 *other* checks we do for the PG security model, under commands/, that
 are the problem here.  The parts of the code that, to be honest, I think
 all us database geeks have historically cared alot less about.

Hmm, interesting.

 What I'm more concerned about is if
 the access control decision in this case were based on u for PG DAC, v
 for SE-PostgreSQL, and w for Robert Haas's Personal Defensive System.
 If that's the case, and our function signature looks like (x,y,u,v,w),
 the we should worry.

 Right, I understand that.  What I offer in reply is that we focus our
 attention on using the OID+SubOID approach, as I'm suggesting, to the
 fullest extent possible through that mechanism, and appreciate that the
 other arguments passed to the function are derived specifically from the
 parser and therefore unlikely to be changed until and unless we change
 the base syntax of the command and calling function, at which time we
 may have to add arguments to the function signature.  This would
 continue at least until we get to the point where we decide that the
 caller needs to be changed because it's got a huge function sig, and
 move it to something like the structure of the executor and the
 equivilant of ExecCheckRTEPerms() would get updated along with it, at
 that time.

What exactly do you mean by a SubOID?  I'm not really following that part.

...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] Adding support for SE-Linux security

2009-12-11 Thread Tom Lane

Robert Haas robertmh...@gmail.com writes:
 What exactly do you mean by a SubOID?  I'm not really following that part.

I assume he's talking about the object reference representation used in
pg_depend, which is actually class OID + object OID + sub-object ID.
The only object type that has sub-objects at the moment is tables,
wherein the sub-objects are columns and the sub-object IDs are column
numbers.  The sub-object ID is zero for all other cases.

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] Adding support for SE-Linux security

2009-12-11 Thread KaiGai Kohei


Robert Haas wrote:

On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost sfr...@snowman.net wrote:

Hrm, I thought I had given a specific example.  Didn't do a good job of
it, apparently.  Let me try to be a bit more clear:

ALTER TABLE x OWNER TO y;

If given the table OID, there's a ton of information we can then pull
about the table- the tablespace, the owner, the schema, the columns, the
privileges, etc, etc.

What we can't possibly figure out from the OID is the value of y.  Yet,
in the PG security model, the value of y matters!  You have to know what
y is to check if y has 'create' rights on the schema.  If it doesn't
(and the user executing the command isn't the superuser) then the
request (under the PG model) is denied.

Does that help clarify my example case?


That case doesn't seem terribly problematic to me.  It seems clear
that we'll want to pass some information about both x and y.  What is
less clear is exactly what the argument types will be, and the right
answer probably depends somewhat on the structure of the existing
code, which I have not looked at.  What I'm more concerned about is if
the access control decision in this case were based on u for PG DAC, v
for SE-PostgreSQL, and w for Robert Haas's Personal Defensive System.
If that's the case, and our function signature looks like (x,y,u,v,w),
the we should worry.


Theoretically, (x,y,u) - (x,y,u,v) - (x,y,u,v,w) may happen.

However, if the new suggested security model is too far from the known
security model, we should consider whether it performs correctly at first
before commit it.
As long as we describe a security model corresponding to database objects,
it is hard to consider a possibility of infinite increasing in the future.

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] Adding support for SE-Linux security

2009-12-11 Thread Bruce Momjian

Tom Lane wrote:
 Robert Haas robertmh...@gmail.com writes:
  Unlike Tom (I think), I do believe that there is demand (possibly only
  from a limited number of people, but demand all the same) for this
  feature.
 
 Please note that I do not think there is *zero* demand for the feature.
 There is obviously some.  What I find highly dubious is whether there is
 enough demand to justify the amount of effort, both short- and long-term,
 that the community would have to put into it.

Well, the bottom line is that this effort should grow the development
and user community of Postgres --- it if doesn't, it is a failure.

  And I also believe that most people in our community are
  generally supportive of the idea, but only a minority are willing to
  put in time to make it happen.  So I have no problem saying to the
  people who want the feature - none of our committers feel like working
  on this.  Sorry.  On the other hand, I also have no problem telling
  them - good news, Bruce Momjian thinks this is a great feature and
  wants to help you get it done.  I *do* have a problem with saying - we
  don't really know whether anyone will ever want to work on this with
  you or not.
 
 If I thought that Bruce could go off in a corner and make this happen
 and it would create no demands on anybody but him and KaiGai-san, I
 would say fine, if that's where you want to spend your time, go for
 it.  But even to state that implied claim is to see how false it is.
 Bruce is pointing to the Windows port, but he didn't make it happen
 by himself, or any close approximation of that.  Everybody who works
 on this project has been affected by that, and we're *still* putting
 significant amounts of time into Windows compatibility, over five years
 later.

The Windows port was primiarly done by Magnus, Claudio Natoli, and
Andrew Dunstan.  The good thing about that group is that their
involvement in Win32 did not take them away from existing Postgres work
--- in fact I think it increased Magnus's and Andrew's involvement.  As
I stated above, I expect the SE-Postgres work to be done mostly by new
people and to expand our development team.  KaiGai is certainly a new
addition, and I think there is already an indication that new people are
getting involved.  

Of course, our existing people will have to help too, but as I stated a
few days ago, I expect security-specific stuff to be maintained mostly
by new people, and our existing folks are going to have to help with
hooks, plus adding things like mandatory access control and row-level
security to base Postgres.  (I do think it is inevitable that those will
be added some day.  I agree the security folks will be accelerating
that.  Hopefully we will get more good out of this than the
inconvenience of this accelerated security stuff.)

 My guess is that a credible SEPostgres offering will require a long-term
 amount of work at least equal to, and very possibly a good deal more
 than, what it took to make a native Windows port.  If SEPostgres could
 bring us even 10% as many new users as the Windows port did, it'd
 probably be a worthwhile use of our resources.  But again, that's an
 assumption that's difficult to type without bursting into laughter.

Odds are SEPostgres will add perhaps 1% new users compared to Win32, but
perhaps very important, energetic, and visible users.  As stated
earlier, the base Postgres security additions like row-level security
are going to be inconvenient, but I do think we will eventually need
them anyway, so I don't see them as SE-Postgres burdens.

I am not replying to many of these emails so I don't appear to be
brow-beating (forcing) the community into accepting this features.  I
might be brow-beating the community, but I don't want to _appear_ to be
brow-beating.  ;-)

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] Adding support for SE-Linux security

On Fri, Dec 11, 2009 at 8:41 PM, Bruce Momjian br...@momjian.us wrote:
 I am not replying to many of these emails so I don't appear to be
 brow-beating (forcing) the community into accepting this features.  I
 might be brow-beating the community, but I don't want to _appear_ to be
 brow-beating.  ;-)

LOL.  At least you're honest...

...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] Adding support for SE-Linux security

2009-12-11 Thread Bruce Momjian

Ron Mayer wrote:
 Bruce Momjian wrote:
  Well, the bottom line is that this effort should grow the development
  and user community of Postgres --- it if doesn't, it is a failure.
 
 Really?  Even if it only allows existing Postgres users and companies to
 expand their use into higher security applications IMHO it's a success.
 
 If a main goal were increasing users, implementing MySQL-isms
 and MSFTSqlServer-isms would seem the biggest bang for the buck.

Well, it should expand the user-base because right now we don't have
many current users who are looking for these features --- if we did, it
would be an easy decision to add these features.  Second, it should add
new developers because we have limited developer resources, and I am not
sure adding additional security is at the top of our priority list, and
we don't have many security-expert developers so by definition we need
more to implement this reliably.

These might be unpleasant opinions, but I believe they are accurate.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] Adding support for SE-Linux security

2009-12-11 Thread Ron Mayer

Bruce Momjian wrote:
 Well, the bottom line is that this effort should grow the development
 and user community of Postgres --- it if doesn't, it is a failure.

Really?  Even if it only allows existing Postgres users and companies to
expand their use into higher security applications IMHO it's a success.

If a main goal were increasing users, implementing MySQL-isms
and MSFTSqlServer-isms would seem the biggest bang for the buck.




-- 
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] Adding support for SE-Linux security

2009-12-10 Thread Robert Haas

On Wed, Dec 9, 2009 at 10:43 PM, Bruce Momjian br...@momjian.us wrote:
 Robert Haas wrote:
 On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian br...@momjian.us wrote:
  If you want to avoid all good reasons for this features and are looking
  for reasons why this patch is a bad idea, I am sure you can find them.

 You seem to be suggesting that our reactions are pure obstructionism,
 or that they have an ulterior motive.

 I am merely stating that this is the same as the Win32 port, and that
 there are many reasons to believe the SE-PostgreSQL patch will cause all
 sorts of problems --- this is not a surprise.  I am giving a realistic
 analysis of the patch  --- if people want to say that thinking of it as
 two separate patches that have to be maintained separately is a terrible
 idea, I have no reply except to say that realistically that is the only
 possible direction I see for this feature in the short term.  Few
 Postgres people modifying the permissions system are going to understand
 how to modify SE-Linux support routines to match their changes.

 I got a similar reaction when I wanted to do the Win32 port, and the
 reasons not to do it were similar to the ones I am hearing now.  Finally
 the agreement was that I could attempt the Win32 port as long as I
 didn't destabilize the rest of the code --- not exactly a resounding
 endorsement.  Looking back I think everyone is glad we did the port, but
 at the time there wasn't much support.  I got the same reaction to
 pg_migrator.

 I am having trouble figuring out when I should heed community concerns,
 and when the concerns are merely because the task is
 hard/messy/difficult.  Frankly, we don't analyze hard/messy/difficult
 tasks very well.   Now, I am not saying that the SE-PostgreSQL patch
 should be pursued, but I am saying that we shouldn't avoid it for these
 reasons, because sometimes hard/messy/difficult is necessary to
 accomplish dramatic software advances.

I don't have any easy answers here.  I'm actually trying not to make a
value judgment about the feature and focus on the technical problems
with the patch.  If those problems are fixed, which as you say
probably doable, then I don't mind seeing it committed.  I think that
the reason we don't analyze hard/messy/difficult problems very well is
because on the one hand you have people saying this feature would be
great.  On the other hand you have people saying this feature will
be a lot of work.  But those things are not opposites.

Unlike Tom (I think), I do believe that there is demand (possibly only
from a limited number of people, but demand all the same) for this
feature.  And I also believe that most people in our community are
generally supportive of the idea, but only a minority are willing to
put in time to make it happen.  So I have no problem saying to the
people who want the feature - none of our committers feel like working
on this.  Sorry.  On the other hand, I also have no problem telling
them - good news, Bruce Momjian thinks this is a great feature and
wants to help you get it done.  I *do* have a problem with saying - we
don't really know whether anyone will ever want to work on this with
you or not.

...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] Adding support for SE-Linux security

2009-12-10 Thread Tom Lane

Robert Haas robertmh...@gmail.com writes:
 Unlike Tom (I think), I do believe that there is demand (possibly only
 from a limited number of people, but demand all the same) for this
 feature.

Please note that I do not think there is *zero* demand for the feature.
There is obviously some.  What I find highly dubious is whether there is
enough demand to justify the amount of effort, both short- and long-term,
that the community would have to put into it.

 And I also believe that most people in our community are
 generally supportive of the idea, but only a minority are willing to
 put in time to make it happen.  So I have no problem saying to the
 people who want the feature - none of our committers feel like working
 on this.  Sorry.  On the other hand, I also have no problem telling
 them - good news, Bruce Momjian thinks this is a great feature and
 wants to help you get it done.  I *do* have a problem with saying - we
 don't really know whether anyone will ever want to work on this with
 you or not.

If I thought that Bruce could go off in a corner and make this happen
and it would create no demands on anybody but him and KaiGai-san, I
would say fine, if that's where you want to spend your time, go for
it.  But even to state that implied claim is to see how false it is.
Bruce is pointing to the Windows port, but he didn't make it happen
by himself, or any close approximation of that.  Everybody who works
on this project has been affected by that, and we're *still* putting
significant amounts of time into Windows compatibility, over five years
later.

My guess is that a credible SEPostgres offering will require a long-term
amount of work at least equal to, and very possibly a good deal more
than, what it took to make a native Windows port.  If SEPostgres could
bring us even 10% as many new users as the Windows port did, it'd
probably be a worthwhile use of our resources.  But again, that's an
assumption that's difficult to type without bursting into laughter.

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] Adding support for SE-Linux security

2009-12-10 Thread David P. Quigley

On Thu, 2009-12-10 at 17:08 -0500, Tom Lane wrote:
 Robert Haas robertmh...@gmail.com writes:
  Unlike Tom (I think), I do believe that there is demand (possibly only
  from a limited number of people, but demand all the same) for this
  feature.
 
 Please note that I do not think there is *zero* demand for the feature.
 There is obviously some.  What I find highly dubious is whether there is
 enough demand to justify the amount of effort, both short- and long-term,
 that the community would have to put into it.
 
  And I also believe that most people in our community are
  generally supportive of the idea, but only a minority are willing to
  put in time to make it happen.  So I have no problem saying to the
  people who want the feature - none of our committers feel like working
  on this.  Sorry.  On the other hand, I also have no problem telling
  them - good news, Bruce Momjian thinks this is a great feature and
  wants to help you get it done.  I *do* have a problem with saying - we
  don't really know whether anyone will ever want to work on this with
  you or not.
 
 If I thought that Bruce could go off in a corner and make this happen
 and it would create no demands on anybody but him and KaiGai-san, I
 would say fine, if that's where you want to spend your time, go for
 it.  But even to state that implied claim is to see how false it is.
 Bruce is pointing to the Windows port, but he didn't make it happen
 by himself, or any close approximation of that.  Everybody who works
 on this project has been affected by that, and we're *still* putting
 significant amounts of time into Windows compatibility, over five years
 later.
 
 My guess is that a credible SEPostgres offering will require a long-term
 amount of work at least equal to, and very possibly a good deal more
 than, what it took to make a native Windows port.  If SEPostgres could
 bring us even 10% as many new users as the Windows port did, it'd
 probably be a worthwhile use of our resources.  But again, that's an
 assumption that's difficult to type without bursting into laughter.
 
   regards, tom lane

So a couple of us in the Maryland/DC area went to the BWPUG meeting last
night and we sat down for two hours and answered a bunch of questions
from Greg Smith, Steve Frost, and a few others. Greg was taking notes
during the entire meeting and I believe he will be starting a thread
with the minutes from the meeting. Greg brought up 5 or 6 concerns that
he has observed in the community about the work including the issue of
who is going to use this. The minutes will give a much better account of
the conversation but Josh Brindle and I have gave examples outside of
DoD where the MAC framework without row based access controls can be
useful. For our purposes in DoD we need the MAC Framework and the row
based access controls but if a good starting point is to just do the
access control over the database objects then it will be useful for some
commercial cases and some limited military cases.

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] Adding support for SE-Linux security

2009-12-10 Thread Andres Freund

Hi,

On Thursday 10 December 2009 23:08:17 Tom Lane wrote:
 My guess is that a credible SEPostgres offering will require a long-term
 amount of work at least equal to, and very possibly a good deal more
 than, what it took to make a native Windows port.  If SEPostgres could
 bring us even 10% as many new users as the Windows port did, it'd
 probably be a worthwhile use of our resources.  But again, that's an
 assumption that's difficult to type without bursting into laughter.
Sorry, could not resist: It could possibly bring us more interesting users...

While mainly an humoristic remark, I think it might even have some truth to 
it...

Andres

-- 
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] Adding support for SE-Linux security

2009-12-10 Thread Mark Mielke


My two cents - if it's desired -

I invariably disable selinux from all of my production machines. Once 
upon a time I tried to work with it time and time again - but it was 
such a head ache to administer for what I considered to be marginal 
gains, that I eventually gave up. Every time I add a server, it needs to 
be setup. Or it runs in tolerant mode at which point I'm not sure what 
value I am really getting at all.


Too many times people have come to me with weird problems of servers not 
starting, or not working properly, and I have now started with the 
question do you have selinux running? try turning it off...


I'm sure some people somewhere love selinux - but I suspect most people 
find the most relief once they turn it off.


I vote for PostgreSQL committers spending their time on things that 
bring value to the most number of people.


Cheers,
mark

--
Mark Mielkem...@mielke.cc


--
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] Adding support for SE-Linux security

2009-12-10 Thread Greg Smith


Tom Lane wrote:

My guess is that a credible SEPostgres offering will require a long-term
amount of work at least equal to, and very possibly a good deal more
than, what it took to make a native Windows port.


Wow, if I thought that was the case I'd be as negative about the whole 
thing as you obviously are.  In my head, I've been mentally bounding the 
effort by thinking that its worst case work would be more like what it 
took to add the role-based security to the system.  I'd think that 
adding a new feature to the existing security setup couldn't be more 
painful than adding security in the first place, right?  I didn't 
carefully watch either play out , but I was under the impression that 
the Windows port was quite a bit more work than that.


Since the current discussion keeps going around in circles, the way I 
was trying to tilt the other thread I started towards was asking the 
question what would need to change in the current PostgreSQL code to 
make the impact of adding the SEPostgreSQL code smaller?  I'd be 
curious to hear any thoughts you had on that topic.  We already sort of 
refactored out adding row-level security as one answer to that, I feel 
like there may be others in there too.


--
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] Adding support for SE-Linux security

2009-12-10 Thread Robert Haas

On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 If I thought that Bruce could go off in a corner and make this happen
 and it would create no demands on anybody but him and KaiGai-san, I
 would say fine, if that's where you want to spend your time, go for
 it.  But even to state that implied claim is to see how false it is.
 Bruce is pointing to the Windows port, but he didn't make it happen
 by himself, or any close approximation of that.  Everybody who works
 on this project has been affected by that, and we're *still* putting
 significant amounts of time into Windows compatibility, over five years
 later.

This is also one of my concerns.  Bruce has been careful to say that
he will either make this happen himself or find others to help.  The
thing is, who are the others, are they people we already trust, and
how do we know whether they'll be around after this is committed?  I'm
excited to see Greg Smith getting more involved in dealing with this
patch-set, and I know Stephen Frost did some reviewing as well, but
overall the community support has been pretty limpid.  It's probably
impossible to completely eliminate the impact of this feature on the
community, but having a core of involved people - preferably including
several committers - who will maintain it would help a lot.  We're not
there yet.

 My guess is that a credible SEPostgres offering will require a long-term
 amount of work at least equal to, and very possibly a good deal more
 than, what it took to make a native Windows port.  If SEPostgres could
 bring us even 10% as many new users as the Windows port did, it'd
 probably be a worthwhile use of our resources.  But again, that's an
 assumption that's difficult to type without bursting into laughter.

The SEPostgres community is surely a lot smaller than the Windows
community, but I'm not sure whether the effort estimate is accurate or
not.  If credible includes row-level security, then I think I
might agree, but right now we're just trying to get off the ground.

...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] Adding support for SE-Linux security

2009-12-10 Thread KaiGai Kohei

David P. Quigley wrote:
 On Thu, 2009-12-10 at 17:08 -0500, Tom Lane wrote:
 Robert Haas robertmh...@gmail.com writes:
 Unlike Tom (I think), I do believe that there is demand (possibly only
 from a limited number of people, but demand all the same) for this
 feature.
 Please note that I do not think there is *zero* demand for the feature.
 There is obviously some.  What I find highly dubious is whether there is
 enough demand to justify the amount of effort, both short- and long-term,
 that the community would have to put into it.

 And I also believe that most people in our community are
 generally supportive of the idea, but only a minority are willing to
 put in time to make it happen.  So I have no problem saying to the
 people who want the feature - none of our committers feel like working
 on this.  Sorry.  On the other hand, I also have no problem telling
 them - good news, Bruce Momjian thinks this is a great feature and
 wants to help you get it done.  I *do* have a problem with saying - we
 don't really know whether anyone will ever want to work on this with
 you or not.
 If I thought that Bruce could go off in a corner and make this happen
 and it would create no demands on anybody but him and KaiGai-san, I
 would say fine, if that's where you want to spend your time, go for
 it.  But even to state that implied claim is to see how false it is.
 Bruce is pointing to the Windows port, but he didn't make it happen
 by himself, or any close approximation of that.  Everybody who works
 on this project has been affected by that, and we're *still* putting
 significant amounts of time into Windows compatibility, over five years
 later.

 My guess is that a credible SEPostgres offering will require a long-term
 amount of work at least equal to, and very possibly a good deal more
 than, what it took to make a native Windows port.  If SEPostgres could
 bring us even 10% as many new users as the Windows port did, it'd
 probably be a worthwhile use of our resources.  But again, that's an
 assumption that's difficult to type without bursting into laughter.

  regards, tom lane
 
 So a couple of us in the Maryland/DC area went to the BWPUG meeting last
 night and we sat down for two hours and answered a bunch of questions
 from Greg Smith, Steve Frost, and a few others. Greg was taking notes
 during the entire meeting and I believe he will be starting a thread
 with the minutes from the meeting. Greg brought up 5 or 6 concerns that
 he has observed in the community about the work including the issue of
 who is going to use this. The minutes will give a much better account of
 the conversation but Josh Brindle and I have gave examples outside of
 DoD where the MAC framework without row based access controls can be
 useful. For our purposes in DoD we need the MAC Framework and the row
 based access controls but if a good starting point is to just do the
 access control over the database objects then it will be useful for some
 commercial cases and some limited military cases.
 

I repent that I live in behind of the earth. :(

I'd like to introduce a story related to Maryland/Baltimore where is the
first city I've visited in US a bit.

The SELinux symposium and developers summit had been held in Baltimore
between 2005 and 2007. (It has been held with LinuxCon at Portland/OR
in recent years.)
I also had a short (works-in-progress) session in the symposium of 2007
to introduce an early concept and design of SE-PostgreSQL.
  http://selinux-symposium.org/2007/wipsbofs.php#sepostgresql

After the 20 minutes talks, I was encircled by several stalwart-guys and
pestered with questions about its behavior and so on. He also gave me
a contact address in .mil domain. It was the first experience for me to
see this domain actually. Maybe, we cannot see these people in PGcon.

What I want to say in this story is that our domain of audiences depends
on our standpoint. If eyesight of developers cannot catch their figures,
we may misunderstand actual voice and demands from (potential) users.
However, it is *never* easy job. Please remind how much cost our company
have spent on marketing research annually.

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] Adding support for SE-Linux security

2009-12-10 Thread Tom Lane

Robert Haas robertmh...@gmail.com writes:
 On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 My guess is that a credible SEPostgres offering will require a long-term
 amount of work at least equal to, and very possibly a good deal more
 than, what it took to make a native Windows port.

 The SEPostgres community is surely a lot smaller than the Windows
 community, but I'm not sure whether the effort estimate is accurate or
 not.  If credible includes row-level security, then I think I
 might agree, but right now we're just trying to get off the ground.

It's been perfectly clear since day one, and was reiterated as recently
as today
http://archives.postgresql.org/message-id/4b21757e.7090...@2ndquadrant.com
that what the security community wants is row-level security.  The
proposals to make SEPostgres drive regular SQL permissions never came
out of anyone from that side, they were proposed by PG people looking
for a manageable first step.  Whatever you might believe about the
potential market for SEPostgres, you should divide by about a hundred
as long as it's only an alternate interface to SQL permissions.  See
particularly here:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG#Revisiting_row-level_security
Without it, it's questionable whether committing the existing
stripped-down patch really accomplishes anything --- how much
clearer can they be?

If you're not prepared to assume that we're going to do row level
security, it's not apparent why we should be embarking on this course
at all.  And if you do assume that, I strongly believe that my effort
estimate above is on the optimistic side.

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] Adding support for SE-Linux security

2009-12-10 Thread Greg Smith


Tom Lane wrote:

It's been perfectly clear since day one, and was reiterated as recently
as today
http://archives.postgresql.org/message-id/4b21757e.7090...@2ndquadrant.com
that what the security community wants is row-level security.


I think David Quigley's comments from earlier today summarize the 
situation better than I did:


For our purposes in DoD we need the MAC Framework and the row based 
access controls.  But if a good starting point is to just do the access 
control over the database objects, then it will be useful for some 
commercial cases and some limited military cases


So it's not without value even in its current Lite form.  But there's 
clearly a whole lot more use-cases that would benefit from a version 
with row filtering.


--
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] Adding support for SE-Linux security

2009-12-10 Thread Robert Haas

On Thu, Dec 10, 2009 at 11:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 If you're not prepared to assume that we're going to do row level
 security, it's not apparent why we should be embarking on this course
 at all.  And if you do assume that, I strongly believe that my effort
 estimate above is on the optimistic side.

Row-level security is going to be a very difficult project, no
question about it.  However, if we implement a general facility rather
than something SE-Linux specific, I think we will have a killer
feature.  I realize it's not for everyone, but for those who need it,
it's kick-ass.

But we have a while before we get to the point where we can even start
worrying about that pain.  Stephen Frost's statements about the way
our access controls are scattered throughout our code are, I think, on
target.  And cleaning that up seems to me to have value independently
of SE-PostgreSQL.  I'm feeling (right now, anyway) like it would make
sense to pursue further the patch that KaiGai submitted for the last
CF and you rejected.  It needed work, but I don't think it was
hopeless, or valueless.

...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] Adding support for SE-Linux security

2009-12-10 Thread KaiGai Kohei

Robert Haas wrote:
 On Thu, Dec 10, 2009 at 11:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 If you're not prepared to assume that we're going to do row level
 security, it's not apparent why we should be embarking on this course
 at all.  And if you do assume that, I strongly believe that my effort
 estimate above is on the optimistic side.
 
 Row-level security is going to be a very difficult project, no
 question about it.

Yes, I also agree it is a reasonable decision to separate row-level
from the initial proposition.

 However, if we implement a general facility rather
 than something SE-Linux specific, I think we will have a killer
 feature.  I realize it's not for everyone, but for those who need it,
 it's kick-ass.
 
 But we have a while before we get to the point where we can even start
 worrying about that pain.  Stephen Frost's statements about the way
 our access controls are scattered throughout our code are, I think, on
 target.  And cleaning that up seems to me to have value independently
 of SE-PostgreSQL.  I'm feeling (right now, anyway) like it would make
 sense to pursue further the patch that KaiGai submitted for the last
 CF and you rejected.  It needed work, but I don't think it was
 hopeless, or valueless.

Here is a few issues to salvage the access control reworks patch.

It tried to provide a set of common entry points both of the default PG
security model and SELinux (and upcoming ones).
However, the default PG model does not have same origin with label-based
mandatory access controls, such as SELinux, from a historical angle.
So, this reworks needed many of unobvious changes to the core routines.
(core routines means code except for enhanced security features.)

It tried to provide a set of comprehensive entry points to replace existing
PG checks at once.
However, the SE-PgSQL/Lite patch covers accesses on only database, schema,
tables and columns. Is it necessary to be comprehensive from the beginning?
It might be too aggressive changes at once.

Frankly, I hesitate to salvage the patch once rejected, as is.

If we implement a set of security hooks, It seems to me the following approach
is reasonable:

* It does not touch the existing PG default checks.
  The purpose of security hooks are to host enhanced security features.

* It does not deploy hooks on which no security provider is now proposed.
  It is important to reduce unnecessary changeset.

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] Adding support for SE-Linux security

2009-12-09 Thread Robert Haas

On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander mag...@hagander.net wrote:
 2009/12/9 Bruce Momjian br...@momjian.us:
 I frankly think the patch should be thought of as the SE-Linux-specific
 directory files, which KaiGai can maintain, and the other parts, which I
 think I can handle.

 I think that's a horribly bad idea.

Me, too.  The ECPG comparison is apt, except that this code is far
more deeply integrated into core.  The idea that the SE-Linux
directory files can be maintained separately from the other parts
does not seem realistic to me.  The problems that are going to occur
here are things like: somebody wants to rearrange some part of the
permissions checking for some reason.  So they move a bunch of code
around and break SE-PostgreSQL.  Someone has to review that patch and
understand the danger it causes.  That's going to require
understanding both the SE-PostgreSQL-specific files and the other
parts, and the relationship between the two of them.

...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] Adding support for SE-Linux security

2009-12-09 Thread Bruce Momjian

Robert Haas wrote:
 On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander mag...@hagander.net wrote:
  2009/12/9 Bruce Momjian br...@momjian.us:
  I frankly think the patch should be thought of as the SE-Linux-specific
  directory files, which KaiGai can maintain, and the other parts, which I
  think I can handle.
 
  I think that's a horribly bad idea.
 
 Me, too.  The ECPG comparison is apt, except that this code is far
 more deeply integrated into core.  The idea that the SE-Linux
 directory files can be maintained separately from the other parts
 does not seem realistic to me.  The problems that are going to occur
 here are things like: somebody wants to rearrange some part of the
 permissions checking for some reason.  So they move a bunch of code
 around and break SE-PostgreSQL.  Someone has to review that patch and
 understand the danger it causes.  That's going to require
 understanding both the SE-PostgreSQL-specific files and the other
 parts, and the relationship between the two of them.

We did something similar for Win32 because it was the only way to do it.
We don't have the luxury of educating our developers on SE-Linux API for
a while --- there is the ideal world, and there is reality.  What this
means is that SE-Linux would break when permissions changes happen, and
the SE-Linux folks will have to come in and clean things up later.

If you want to avoid all good reasons for this features and are looking
for reasons why this patch is a bad idea, I am sure you can find them.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] Adding support for SE-Linux security

2009-12-09 Thread KaiGai Kohei

Bruce Momjian wrote:
 Robert Haas wrote:
 On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander mag...@hagander.net wrote:
 2009/12/9 Bruce Momjian br...@momjian.us:
 I frankly think the patch should be thought of as the SE-Linux-specific
 directory files, which KaiGai can maintain, and the other parts, which I
 think I can handle.
 I think that's a horribly bad idea.
 Me, too.  The ECPG comparison is apt, except that this code is far
 more deeply integrated into core.  The idea that the SE-Linux
 directory files can be maintained separately from the other parts
 does not seem realistic to me.  The problems that are going to occur
 here are things like: somebody wants to rearrange some part of the
 permissions checking for some reason.  So they move a bunch of code
 around and break SE-PostgreSQL.  Someone has to review that patch and
 understand the danger it causes.  That's going to require
 understanding both the SE-PostgreSQL-specific files and the other
 parts, and the relationship between the two of them.
 
 We did something similar for Win32 because it was the only way to do it.
 We don't have the luxury of educating our developers on SE-Linux API for
 a while --- there is the ideal world, and there is reality.  What this
 means is that SE-Linux would break when permissions changes happen, and
 the SE-Linux folks will have to come in and clean things up later.
 
 If you want to avoid all good reasons for this features and are looking
 for reasons why this patch is a bad idea, I am sure you can find them.
 

Right, I (and my employer) offers development and maintenance resource
for the feature. If I'll be busy in future days, it means I'm devotedly
working on this feature. When we need to change permission mechanism in
the future, we can provide our efforts not to break them.

-- 
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] Adding support for SE-Linux security

2009-12-09 Thread Robert Haas

On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian br...@momjian.us wrote:
 If you want to avoid all good reasons for this features and are looking
 for reasons why this patch is a bad idea, I am sure you can find them.

You seem to be suggesting that our reactions are pure obstructionism,
or that they have an ulterior motive.

...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] Adding support for SE-Linux security

2009-12-09 Thread Bruce Momjian

Robert Haas wrote:
 On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian br...@momjian.us wrote:
  If you want to avoid all good reasons for this features and are looking
  for reasons why this patch is a bad idea, I am sure you can find them.
 
 You seem to be suggesting that our reactions are pure obstructionism,
 or that they have an ulterior motive.

I am merely stating that this is the same as the Win32 port, and that
there are many reasons to believe the SE-PostgreSQL patch will cause all
sorts of problems --- this is not a surprise.  I am giving a realistic
analysis of the patch  --- if people want to say that thinking of it as
two separate patches that have to be maintained separately is a terrible
idea, I have no reply except to say that realistically that is the only
possible direction I see for this feature in the short term.  Few
Postgres people modifying the permissions system are going to understand
how to modify SE-Linux support routines to match their changes.

I got a similar reaction when I wanted to do the Win32 port, and the
reasons not to do it were similar to the ones I am hearing now.  Finally
the agreement was that I could attempt the Win32 port as long as I
didn't destabilize the rest of the code --- not exactly a resounding
endorsement.  Looking back I think everyone is glad we did the port, but
at the time there wasn't much support.  I got the same reaction to
pg_migrator.

I am having trouble figuring out when I should heed community concerns,
and when the concerns are merely because the task is
hard/messy/difficult.  Frankly, we don't analyze hard/messy/difficult
tasks very well.   Now, I am not saying that the SE-PostgreSQL patch
should be pursued, but I am saying that we shouldn't avoid it for these
reasons, because sometimes hard/messy/difficult is necessary to
accomplish dramatic software advances.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] Adding support for SE-Linux security

On Mon, 2009-12-07 at 22:25 -0500, Greg Smith wrote:
 David P. Quigley wrote:
  Not to start a flame war here about access control models but you gave 3
  different examples one of which I don't think has any means to do
  anything productive here.
 You won't be starting a flame war for the same reason some of the
 community members are so concerned about this patch. There aren't enough
 people familiar with this part of the security field within our database
 developer community to even be able to answer fairly basic questions
 like the one you just clarified. If you can help bring more qualified
 reviewers to bear on that, it would be extremely helpful. I even tried
 to organize a meetup between PostgreSQL hackers working in this area and
 the security people I knew around here (Baltimore/DC) last year, but
 just couldn't find any interested enough to show. Other than a brief
 visit on this list from some of the Tresys guys, we haven't seen much
 input here beyond that offered by the patch author, who's obviously
 qualified but at the end of the day is still only one opinion. He's also
 not in a good position to tell other people their ideas are misinformed
 either.
 

I can't make any guarantees on who I can drag to a meeting but if you
wanted to try to organize another meeting between the Postgres people
and some of us I can try to organize it on our end. One of my coworkers
that does a lot of commenting on stuff like this is on leave at the
moment but when he gets back I'll discuss it with him. I'll also talk
with some of the other people in the area on our end to see what I can
arrange.

If you have any questions in the meantime feel free to ask. If there are
any specific parts of the patch that you'd like discussed I can do that
as well. I do have to agree though that I'd rather see KaiGai's original
security plugin framework go in and then merge a particular security
module after that.From what I see it would require at least the hook
framework and the label storage mechanism. I feel bad saying that
knowing the KaiGai spent a lot of time ripping all of that out. However
if you are concerned about supporting more than just SELinux as a MAC
model then the plugin framework he originally proposed is the better
solution. 

I'd be willing to take a look at the framework and see if it really is
SELinux centric. If it is we can figure out if there is a way to
accomodate something like SMACK and FMAC. I'd like to hear from someone
with more extensive experience with Solaris Trusted Extensions about how
TX would make use of this. I have a feeling it would be similar to the
way it deals with NFS which is by having the process exist in the global
zone as a privileged process and then multi-plexes it to the remaining
zones. That way their getpeercon would get a label derived from the
zone.

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] Adding support for SE-Linux security

On Tue, Dec 8, 2009 at 10:07 AM, David P. Quigley dpqu...@tycho.nsa.gov wrote:
 I'd be willing to take a look at the framework and see if it really is
 SELinux centric. If it is we can figure out if there is a way to
 accomodate something like SMACK and FMAC. I'd like to hear from someone
 with more extensive experience with Solaris Trusted Extensions about how
 TX would make use of this. I have a feeling it would be similar to the
 way it deals with NFS which is by having the process exist in the global
 zone as a privileged process and then multi-plexes it to the remaining
 zones. That way their getpeercon would get a label derived from the
 zone.

Well, the old patches should still be available in the mailing list
archives.  Maybe going back and looking at that code would be a good
place to start.  The non-ripped-out code has been cleaned up a lot
since then, but at least it's a place to start.

...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] Adding support for SE-Linux security

On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley dpqu...@tycho.nsa.gov wrote:
 On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
 On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian br...@momjian.us wrote:
  As Alvaro mentioned, the original patch used ACE but it added too much
  code so the community requested its removal from the patch.  It could be
  re-added if we have a need.

 Well, there's no point in putting that framework back in unless we can
 make it sufficiently general that it could be used to serve the needs
 of more than one security model.  And so far, the signs have not been
 promising.  David Quigley suggests downthread that making a truly
 general model isn't really possible, and he may be right, or not.  I
 was just mentioning that it's an angle I have been thinking about
 investigating, but it may be a dead end.

 The real issue is making the code committable, and then maintaining
 it, as Tom rightly says, forever.  We've got to make sure that we're
 willing to take that on before we do it, and I don't think it's a
 small task.  It isn't so much whether we want the feature as whether
 the level of effort is proportionate to the benefit.

 ...Robert


 So the issue with generality is that path name based MAC has a different
 set of requirements than label based does. If you want to acomodate
 several types of label based MAC models then a framework can be
 developed for that similar to the one in the Linux Kernel. I asked
 around after I sent the email yesterday and from what I understand
 AppArmor does not have the concept of a userspace object manager so I
 don't know what they'd do in this area. I'm sure they could come up with
 a scheme to write policy for the database but I don't know how useful it
 would be.

 If you look at the LSM framework in the Linux Kernel recently there have
 been hooks added to accomodate path based MAC systems so it can be done
 but adds another set of hooks. The important goal here though in
 designing a framework is to make sure that you have a comprehensive list
 of the objects you want to mediate and make sure you put the proper
 enforcement points in. Someone may come along later and want to mediate
 a new object or some new functionality may come along that introduces a
 new object so a hook may then need to be added. Something to realize as
 well is that a security model may not want to implement all of the hooks
 and it doesn't have to. In the case of no module being loaded or someone
 not wanting the loadable security module framework I'm sure we can
 provide an option to reduce overhead or compile the framework out
 completely.

 I'll take a look at his patches for the framework that KaiGai originally
 proposed.

It sounds like the pathname-based schemes are not really designed to
work inside of a database anyway, so my first thought is we shouldn't
worry about them.  The label-based schemes are by their nature
designed to apply in an arbitrary context being applied to arbitrary
objects.

...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] Adding support for SE-Linux security

On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote:
 On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley dpqu...@tycho.nsa.gov 
 wrote:
  On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
  On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian br...@momjian.us wrote:
   As Alvaro mentioned, the original patch used ACE but it added too much
   code so the community requested its removal from the patch.  It could be
   re-added if we have a need.
 
  Well, there's no point in putting that framework back in unless we can
  make it sufficiently general that it could be used to serve the needs
  of more than one security model.  And so far, the signs have not been
  promising.  David Quigley suggests downthread that making a truly
  general model isn't really possible, and he may be right, or not.  I
  was just mentioning that it's an angle I have been thinking about
  investigating, but it may be a dead end.
 
  The real issue is making the code committable, and then maintaining
  it, as Tom rightly says, forever.  We've got to make sure that we're
  willing to take that on before we do it, and I don't think it's a
  small task.  It isn't so much whether we want the feature as whether
  the level of effort is proportionate to the benefit.
 
  ...Robert
 
 
  So the issue with generality is that path name based MAC has a different
  set of requirements than label based does. If you want to acomodate
  several types of label based MAC models then a framework can be
  developed for that similar to the one in the Linux Kernel. I asked
  around after I sent the email yesterday and from what I understand
  AppArmor does not have the concept of a userspace object manager so I
  don't know what they'd do in this area. I'm sure they could come up with
  a scheme to write policy for the database but I don't know how useful it
  would be.
 
  If you look at the LSM framework in the Linux Kernel recently there have
  been hooks added to accomodate path based MAC systems so it can be done
  but adds another set of hooks. The important goal here though in
  designing a framework is to make sure that you have a comprehensive list
  of the objects you want to mediate and make sure you put the proper
  enforcement points in. Someone may come along later and want to mediate
  a new object or some new functionality may come along that introduces a
  new object so a hook may then need to be added. Something to realize as
  well is that a security model may not want to implement all of the hooks
  and it doesn't have to. In the case of no module being loaded or someone
  not wanting the loadable security module framework I'm sure we can
  provide an option to reduce overhead or compile the framework out
  completely.
 
  I'll take a look at his patches for the framework that KaiGai originally
  proposed.
 
 It sounds like the pathname-based schemes are not really designed to
 work inside of a database anyway, so my first thought is we shouldn't
 worry about them.  The label-based schemes are by their nature
 designed to apply in an arbitrary context being applied to arbitrary
 objects.
 
 ...Robert


So I was reading through a set of slides that KaiGai has and he
mentioned a May commitfest link and I looked for the comments related to
his PGACE patches. I've been crawling through the commitfest paces so I
can figure out what the latest version of the pgace patch is. Does
anyone know when the patch was reduced to what it is today?

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] Adding support for SE-Linux security

2009-12-08 Thread Chad Sellers

On 12/8/09 11:51 AM, David P. Quigley dpqu...@tycho.nsa.gov wrote:

 On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote:
 On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley dpqu...@tycho.nsa.gov
 wrote:
 On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
 On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian br...@momjian.us wrote:
 As Alvaro mentioned, the original patch used ACE but it added too much
 code so the community requested its removal from the patch.  It could be
 re-added if we have a need.
 
 Well, there's no point in putting that framework back in unless we can
 make it sufficiently general that it could be used to serve the needs
 of more than one security model.  And so far, the signs have not been
 promising.  David Quigley suggests downthread that making a truly
 general model isn't really possible, and he may be right, or not.  I
 was just mentioning that it's an angle I have been thinking about
 investigating, but it may be a dead end.
 
 The real issue is making the code committable, and then maintaining
 it, as Tom rightly says, forever.  We've got to make sure that we're
 willing to take that on before we do it, and I don't think it's a
 small task.  It isn't so much whether we want the feature as whether
 the level of effort is proportionate to the benefit.
 
 ...Robert
 
 
 So the issue with generality is that path name based MAC has a different
 set of requirements than label based does. If you want to acomodate
 several types of label based MAC models then a framework can be
 developed for that similar to the one in the Linux Kernel. I asked
 around after I sent the email yesterday and from what I understand
 AppArmor does not have the concept of a userspace object manager so I
 don't know what they'd do in this area. I'm sure they could come up with
 a scheme to write policy for the database but I don't know how useful it
 would be.
 
 If you look at the LSM framework in the Linux Kernel recently there have
 been hooks added to accomodate path based MAC systems so it can be done
 but adds another set of hooks. The important goal here though in
 designing a framework is to make sure that you have a comprehensive list
 of the objects you want to mediate and make sure you put the proper
 enforcement points in. Someone may come along later and want to mediate
 a new object or some new functionality may come along that introduces a
 new object so a hook may then need to be added. Something to realize as
 well is that a security model may not want to implement all of the hooks
 and it doesn't have to. In the case of no module being loaded or someone
 not wanting the loadable security module framework I'm sure we can
 provide an option to reduce overhead or compile the framework out
 completely.
 
 I'll take a look at his patches for the framework that KaiGai originally
 proposed.
 
 It sounds like the pathname-based schemes are not really designed to
 work inside of a database anyway, so my first thought is we shouldn't
 worry about them.  The label-based schemes are by their nature
 designed to apply in an arbitrary context being applied to arbitrary
 objects.
 
 ...Robert
 
 
 So I was reading through a set of slides that KaiGai has and he
 mentioned a May commitfest link and I looked for the comments related to
 his PGACE patches. I've been crawling through the commitfest paces so I
 can figure out what the latest version of the pgace patch is. Does
 anyone know when the patch was reduced to what it is today?
 
 Dave
 
I'm another SELinux developer and I'd like to help out where I can here. I'm
a bit confused by this discussion of PGACE. I thought the postgresql
community agreed that they wanted this removed in order to make the patch
size smaller. Has that changed? Is the increase in patch size now
acceptable? Sorry if I'm joining the conversation late.

Thanks,
Chad Sellers


-- 
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] Adding support for SE-Linux security

On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers csell...@tresys.com wrote:
 On 12/8/09 11:51 AM, David P. Quigley dpqu...@tycho.nsa.gov wrote:

 On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote:
 On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley dpqu...@tycho.nsa.gov
 wrote:
 On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
 On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian br...@momjian.us wrote:
 As Alvaro mentioned, the original patch used ACE but it added too much
 code so the community requested its removal from the patch.  It could be
 re-added if we have a need.

 Well, there's no point in putting that framework back in unless we can
 make it sufficiently general that it could be used to serve the needs
 of more than one security model.  And so far, the signs have not been
 promising.  David Quigley suggests downthread that making a truly
 general model isn't really possible, and he may be right, or not.  I
 was just mentioning that it's an angle I have been thinking about
 investigating, but it may be a dead end.

 The real issue is making the code committable, and then maintaining
 it, as Tom rightly says, forever.  We've got to make sure that we're
 willing to take that on before we do it, and I don't think it's a
 small task.  It isn't so much whether we want the feature as whether
 the level of effort is proportionate to the benefit.

 ...Robert


 So the issue with generality is that path name based MAC has a different
 set of requirements than label based does. If you want to acomodate
 several types of label based MAC models then a framework can be
 developed for that similar to the one in the Linux Kernel. I asked
 around after I sent the email yesterday and from what I understand
 AppArmor does not have the concept of a userspace object manager so I
 don't know what they'd do in this area. I'm sure they could come up with
 a scheme to write policy for the database but I don't know how useful it
 would be.

 If you look at the LSM framework in the Linux Kernel recently there have
 been hooks added to accomodate path based MAC systems so it can be done
 but adds another set of hooks. The important goal here though in
 designing a framework is to make sure that you have a comprehensive list
 of the objects you want to mediate and make sure you put the proper
 enforcement points in. Someone may come along later and want to mediate
 a new object or some new functionality may come along that introduces a
 new object so a hook may then need to be added. Something to realize as
 well is that a security model may not want to implement all of the hooks
 and it doesn't have to. In the case of no module being loaded or someone
 not wanting the loadable security module framework I'm sure we can
 provide an option to reduce overhead or compile the framework out
 completely.

 I'll take a look at his patches for the framework that KaiGai originally
 proposed.

 It sounds like the pathname-based schemes are not really designed to
 work inside of a database anyway, so my first thought is we shouldn't
 worry about them.  The label-based schemes are by their nature
 designed to apply in an arbitrary context being applied to arbitrary
 objects.

 ...Robert


 So I was reading through a set of slides that KaiGai has and he
 mentioned a May commitfest link and I looked for the comments related to
 his PGACE patches. I've been crawling through the commitfest paces so I
 can figure out what the latest version of the pgace patch is. Does
 anyone know when the patch was reduced to what it is today?

 Dave

 I'm another SELinux developer and I'd like to help out where I can here. I'm
 a bit confused by this discussion of PGACE. I thought the postgresql
 community agreed that they wanted this removed in order to make the patch
 size smaller. Has that changed? Is the increase in patch size now
 acceptable? Sorry if I'm joining the conversation late.

 Thanks,
 Chad Sellers

Nothing's been decided.  We're just trying to figure out the best way
to tackle the problem.  I think the main question here is who if
anyone from among the committers is willing to put in the time and
effort to maintain this feature over the short and long haul, but
that's sort of an internal project issue.  I was just thinking out
loud about whether it was possible and/or desirable to try to
modularize this a bit so that it could be used for more than just
SE-Linux.  Obviously, the labeling stuff could be generalize to
accomodate a label from an arbitrary security system, but that's only
a small piece of the problem.

One of the major and fundamental stumbling blocks we've run into is
that every solution we've looked at so far seems to involve adding
SE-Linux-specific checks in many places in the code.  It would be nice
if it were possible to use the exist permissions-checking functions
and have them check a few more things while they're at it, but it's
looking like that won't be feasible, or at least no one's come up with
a plausible design

Re: [HACKERS] Adding support for SE-Linux security

2009-12-08 Thread Tom Lane

Robert Haas robertmh...@gmail.com writes:
 One of the major and fundamental stumbling blocks we've run into is
 that every solution we've looked at so far seems to involve adding
 SE-Linux-specific checks in many places in the code.  It would be nice
 if it were possible to use the exist permissions-checking functions
 and have them check a few more things while they're at it, but it's
 looking like that won't be feasible, or at least no one's come up with
 a plausible design yet.

I don't think that it's about SELinux.  The real issue here is that
KaiGai-san is about a mile out in front of the PG hackers community
in terms of his ambitions for the scope of what can be controlled by
security policy.  If the patch were only doing what the community has
actually agreed to, there would be little need for it to touch anything
but the aclcheck functions.

Now I recognize that a large part of the potential attraction in this
for the security community is exactly the idea of having fine-grain
security control.  But if you ever want anything significantly different
from SQL-standard permission mechanisms, there's going to have to be a
whole lot more work done.  Basically, nobody in the PG community has got
any confidence either in the overall design or the implementation
details for locking things down that aren't already controlled by SQL
permission mechanisms.

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] Adding support for SE-Linux security

On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 One of the major and fundamental stumbling blocks we've run into is
 that every solution we've looked at so far seems to involve adding
 SE-Linux-specific checks in many places in the code.  It would be nice
 if it were possible to use the exist permissions-checking functions
 and have them check a few more things while they're at it, but it's
 looking like that won't be feasible, or at least no one's come up with
 a plausible design yet.

 I don't think that it's about SELinux.  The real issue here is that
 KaiGai-san is about a mile out in front of the PG hackers community
 in terms of his ambitions for the scope of what can be controlled by
 security policy.  If the patch were only doing what the community has
 actually agreed to, there would be little need for it to touch anything
 but the aclcheck functions.

 Now I recognize that a large part of the potential attraction in this
 for the security community is exactly the idea of having fine-grain
 security control.  But if you ever want anything significantly different
 from SQL-standard permission mechanisms, there's going to have to be a
 whole lot more work done.  Basically, nobody in the PG community has got
 any confidence either in the overall design or the implementation
 details for locking things down that aren't already controlled by SQL
 permission mechanisms.

I think that's basically right.  Further, I think this is basically a
resource issue.  If you were inclined to spend a large amount of your
time on this problem, you could either gain confidence in the present
design and implementation or come up with a new one in which you did
have confidence.  But it doesn't seem important enough to you (or your
employer) for the amount of time it would take, so you're not.  I
think there are other committers and community members in a similar
situation - basically all of them.

...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] Adding support for SE-Linux security

2009-12-08 Thread Chad Sellers

On 12/8/09 12:36 PM, Robert Haas robertmh...@gmail.com wrote:

 On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers csell...@tresys.com wrote:
 On 12/8/09 11:51 AM, David P. Quigley dpqu...@tycho.nsa.gov wrote:
 
 On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote:
 On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley dpqu...@tycho.nsa.gov
 wrote:
 On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
 On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian br...@momjian.us wrote:
 As Alvaro mentioned, the original patch used ACE but it added too much
 code so the community requested its removal from the patch.  It could be
 re-added if we have a need.
 
 Well, there's no point in putting that framework back in unless we can
 make it sufficiently general that it could be used to serve the needs
 of more than one security model.  And so far, the signs have not been
 promising.  David Quigley suggests downthread that making a truly
 general model isn't really possible, and he may be right, or not.  I
 was just mentioning that it's an angle I have been thinking about
 investigating, but it may be a dead end.
 
 The real issue is making the code committable, and then maintaining
 it, as Tom rightly says, forever.  We've got to make sure that we're
 willing to take that on before we do it, and I don't think it's a
 small task.  It isn't so much whether we want the feature as whether
 the level of effort is proportionate to the benefit.
 
 ...Robert
 
 
 So the issue with generality is that path name based MAC has a different
 set of requirements than label based does. If you want to acomodate
 several types of label based MAC models then a framework can be
 developed for that similar to the one in the Linux Kernel. I asked
 around after I sent the email yesterday and from what I understand
 AppArmor does not have the concept of a userspace object manager so I
 don't know what they'd do in this area. I'm sure they could come up with
 a scheme to write policy for the database but I don't know how useful it
 would be.
 
 If you look at the LSM framework in the Linux Kernel recently there have
 been hooks added to accomodate path based MAC systems so it can be done
 but adds another set of hooks. The important goal here though in
 designing a framework is to make sure that you have a comprehensive list
 of the objects you want to mediate and make sure you put the proper
 enforcement points in. Someone may come along later and want to mediate
 a new object or some new functionality may come along that introduces a
 new object so a hook may then need to be added. Something to realize as
 well is that a security model may not want to implement all of the hooks
 and it doesn't have to. In the case of no module being loaded or someone
 not wanting the loadable security module framework I'm sure we can
 provide an option to reduce overhead or compile the framework out
 completely.
 
 I'll take a look at his patches for the framework that KaiGai originally
 proposed.
 
 It sounds like the pathname-based schemes are not really designed to
 work inside of a database anyway, so my first thought is we shouldn't
 worry about them.  The label-based schemes are by their nature
 designed to apply in an arbitrary context being applied to arbitrary
 objects.
 
 ...Robert
 
 
 So I was reading through a set of slides that KaiGai has and he
 mentioned a May commitfest link and I looked for the comments related to
 his PGACE patches. I've been crawling through the commitfest paces so I
 can figure out what the latest version of the pgace patch is. Does
 anyone know when the patch was reduced to what it is today?
 
 Dave
 
 I'm another SELinux developer and I'd like to help out where I can here. I'm
 a bit confused by this discussion of PGACE. I thought the postgresql
 community agreed that they wanted this removed in order to make the patch
 size smaller. Has that changed? Is the increase in patch size now
 acceptable? Sorry if I'm joining the conversation late.
 
 Thanks,
 Chad Sellers
 
 Nothing's been decided.

Sorry, my mistake. This mailing list moves pretty quick so it's hard to
catch up with everything.

 We're just trying to figure out the best way
 to tackle the problem.  I think the main question here is who if
 anyone from among the committers is willing to put in the time and
 effort to maintain this feature over the short and long haul, but
 that's sort of an internal project issue.  I was just thinking out
 loud about whether it was possible and/or desirable to try to
 modularize this a bit so that it could be used for more than just
 SE-Linux. 

So, a generalized framework is nice in that it supports multiple models, but
it does bring with it an additional maintenance burden. I'm sure that's been
discussed at length already.

I will say that it's almost impossible to place hooks properly for imaginary
users. So, if you create a framework, it's probably just a placeholder with
hooks for the one user (SEPostgreSQL) that will later have

Re: [HACKERS] Adding support for SE-Linux security

On Tue, 2009-12-08 at 14:22 -0500, Robert Haas wrote:
 On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
  Robert Haas robertmh...@gmail.com writes:
  One of the major and fundamental stumbling blocks we've run into is
  that every solution we've looked at so far seems to involve adding
  SE-Linux-specific checks in many places in the code.  It would be nice
  if it were possible to use the exist permissions-checking functions
  and have them check a few more things while they're at it, but it's
  looking like that won't be feasible, or at least no one's come up with
  a plausible design yet.
 
  I don't think that it's about SELinux.  The real issue here is that
  KaiGai-san is about a mile out in front of the PG hackers community
  in terms of his ambitions for the scope of what can be controlled by
  security policy.  If the patch were only doing what the community has
  actually agreed to, there would be little need for it to touch anything
  but the aclcheck functions.
 
  Now I recognize that a large part of the potential attraction in this
  for the security community is exactly the idea of having fine-grain
  security control.  But if you ever want anything significantly different
  from SQL-standard permission mechanisms, there's going to have to be a
  whole lot more work done.  Basically, nobody in the PG community has got
  any confidence either in the overall design or the implementation
  details for locking things down that aren't already controlled by SQL
  permission mechanisms.
 
 I think that's basically right.  Further, I think this is basically a
 resource issue.  If you were inclined to spend a large amount of your
 time on this problem, you could either gain confidence in the present
 design and implementation or come up with a new one in which you did
 have confidence.  But it doesn't seem important enough to you (or your
 employer) for the amount of time it would take, so you're not.  I
 think there are other committers and community members in a similar
 situation - basically all of them.
 
 ...Robert
 


I have to agree with Chad (downthread) that I don't see much in KaiGai's
hook patch that prevents its use by other security models. I will say
though one thing that might have been done wrong was with how it was
presented. In actuality his patch set is two projects (at least). The
first is the framework. So I think the goal should have been to get the
framework integrated first and then work on the SELinux module after
that. The framework patch alone consists of at least 4 sets of logical
changes that could have been separated to make review easier. Once the
framework was in, work could be done to get the SELinux module in while
reducing overhead from the case where no module is loaded.

So with regard to confidence in the design I think that part of the
reason for the skepticism in the fact that it was such a large code
drop. Even the separated parts were very large. I think if the framework
patches are broken up more logically and in a way that is easier to
discuss then that might help the community get a grasp on what it is
trying to accomplish. 

In terms of documentation I was reading through the wiki at
sepgsql.googlecode.com and aside from some wordsmithing/grammar things
it is pretty solid with describing what it is trying to accomplish. One
problem that I see is that at first glance it does appear to be very
SELinux centric. It describes access based on types and SELinux contexts
which is understandable based on the fact that it describes the
framework and the module. Something to note is that the documentation
describes an object model for the program. I think that would be a good
place to focus the discussion with respect to a framework if we decide
to pursue it.

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] Adding support for SE-Linux security

2009-12-08 Thread Stephen Frost

* Robert Haas (robertmh...@gmail.com) wrote:
 One of the major and fundamental stumbling blocks we've run into is
 that every solution we've looked at so far seems to involve adding
 SE-Linux-specific checks in many places in the code.  

I've really got to take exception to this.  I've only been following
along and not really participating because, to be honest, I'm frustrated
with how this has gone down.  In the end there were at least two
patches, in my view, that *didn't* involve adding SE-Linux-specific
checks everywhere.  The patch that I reviewed that got thrown out by
Tom, and the original PGACE framework.  Both of those added alot of
*hooks*, because they were necessary, but nothing made those hooks
particularly SELinux-specifc.  We're hearing alot about things being
SELinux-specific from people who also profess to not know SELinux.

Indeed, as I recall, the patch I reviewed was primairly trying to just
addess pulling out the hooks necessary for the existing PostgreSQL
security model.  Very little of it was SE-Linux specific *anything*.

I contend that while the specific hooks which would be added *in
places that don't already have checks* (in most places, the hook was
added to replace an existing check) are hooks that then make sense
for SELinux, they would also make sense for other frameworks.  They
may also not be a complete list, but once the *framework* is in
place, adding new hooks (presuming another model would like a hook
somewhere that SELinux and the existing PG security framework don't)
should not require some kind of forklift upgrade.

 It would be nice
 if it were possible to use the exist permissions-checking functions
 and have them check a few more things while they're at it, but it's
 looking like that won't be feasible, or at least no one's come up with
 a plausible design yet.  

The problem is that the existing permissions-checking is done all over
the place.  That's not ideal from the get-go, in my opinion.
Unfortuantely, when we moved all of the permissions-checking to a single
place, it required knowing about alot of the backend, which Tom took
exception to.  I agree that's frustrating, but I don't see it as a
particular reason to throw out the entire concept of a modular security
framework.  Perhaps we need to better expose just those pieces the
security framework cares about from the other parts of the backend- it's
entirely likely that the reason it has to know about everything is that,
due to where all the existing security checks are, they just (ab)used
the fact that they had access to that information at hand for that
object type.

 Consequently there are checks spread
 throughout the code, which definitely complicates both validation and
 maintenance.  One question I have is - are the places where those
 checks are placed specific to SE-Linux, or would they be applicable to
 any sort of label-based MAC?

The patch which I worked with Kaigai on was specifically geared to first
try to get a patch which addressed the existing PG security model in a
modular way, to allow additional hooks to be added later in places which
needed them, and to provide the information for other models to make a
decision about the permission.  I don't feel it was particularly
SE-Linux specific at all, but rather a first step towards being able to
support something beyond the model we have today (anything..).

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Adding support for SE-Linux security

On Tue, Dec 8, 2009 at 2:50 PM, David P. Quigley dpqu...@tycho.nsa.gov wrote:
 On Tue, 2009-12-08 at 14:22 -0500, Robert Haas wrote:
 On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
  Robert Haas robertmh...@gmail.com writes:
  One of the major and fundamental stumbling blocks we've run into is
  that every solution we've looked at so far seems to involve adding
  SE-Linux-specific checks in many places in the code.  It would be nice
  if it were possible to use the exist permissions-checking functions
  and have them check a few more things while they're at it, but it's
  looking like that won't be feasible, or at least no one's come up with
  a plausible design yet.
 
  I don't think that it's about SELinux.  The real issue here is that
  KaiGai-san is about a mile out in front of the PG hackers community
  in terms of his ambitions for the scope of what can be controlled by
  security policy.  If the patch were only doing what the community has
  actually agreed to, there would be little need for it to touch anything
  but the aclcheck functions.
 
  Now I recognize that a large part of the potential attraction in this
  for the security community is exactly the idea of having fine-grain
  security control.  But if you ever want anything significantly different
  from SQL-standard permission mechanisms, there's going to have to be a
  whole lot more work done.  Basically, nobody in the PG community has got
  any confidence either in the overall design or the implementation
  details for locking things down that aren't already controlled by SQL
  permission mechanisms.

 I think that's basically right.  Further, I think this is basically a
 resource issue.  If you were inclined to spend a large amount of your
 time on this problem, you could either gain confidence in the present
 design and implementation or come up with a new one in which you did
 have confidence.  But it doesn't seem important enough to you (or your
 employer) for the amount of time it would take, so you're not.  I
 think there are other committers and community members in a similar
 situation - basically all of them.

 I have to agree with Chad (downthread) that I don't see much in KaiGai's
 hook patch that prevents its use by other security models. I will say
 though one thing that might have been done wrong was with how it was
 presented. In actuality his patch set is two projects (at least). The
 first is the framework. So I think the goal should have been to get the
 framework integrated first and then work on the SELinux module after
 that. The framework patch alone consists of at least 4 sets of logical
 changes that could have been separated to make review easier. Once the
 framework was in, work could be done to get the SELinux module in while
 reducing overhead from the case where no module is loaded.

I can say from experience that this project is very skeptical of
frameworks that aren't accompanied by at least one, and preferably
multiple, working implementations.  So there is a bit of a chicken and
egg problem here.  What can sometimes work is to say, look, here's a
place where I can put a hook and later I will do something complex
with it but here are a couple of relatively simple but useful examples
to get started.  The examples form the justification for the commit
because they are independently useful, but they are much simpler than
what the framework may eventually end up being used for.

I don't believe that this approach is feasible for SE-PostgreSQL.  A
simple version of label security is still going to be very
complicated, and there are probably even fewer customers for such a
thing than there are for SE-PostgreSQL.

 So with regard to confidence in the design I think that part of the
 reason for the skepticism in the fact that it was such a large code
 drop. Even the separated parts were very large.

Definitely true.

 I think if the framework
 patches are broken up more logically and in a way that is easier to
 discuss then that might help the community get a grasp on what it is
 trying to accomplish.

Maybe, maybe not.  Nobody's going to commit anything unless it's a
complete feature.  It can be a cut-down feature, but it has to be of
independent use.  If there are parts that can be peeled off of
SE-PostgreSQL and committed independently to some good benefit, then I
think that's a great idea.  But if it's just a separation of the patch
for clarity, I don't think there's much value in that.

 In terms of documentation I was reading through the wiki at
 sepgsql.googlecode.com and aside from some wordsmithing/grammar things
 it is pretty solid with describing what it is trying to accomplish. One
 problem that I see is that at first glance it does appear to be very
 SELinux centric. It describes access based on types and SELinux contexts
 which is understandable based on the fact that it describes the
 framework and the module. Something to note is that the documentation
 describes an object

Re: [HACKERS] Adding support for SE-Linux security

On Tue, 2009-12-08 at 15:24 -0500, Stephen Frost wrote:
 * Robert Haas (robertmh...@gmail.com) wrote:
  One of the major and fundamental stumbling blocks we've run into is
  that every solution we've looked at so far seems to involve adding
  SE-Linux-specific checks in many places in the code.  
 
 I've really got to take exception to this.  I've only been following
 along and not really participating because, to be honest, I'm frustrated
 with how this has gone down.  In the end there were at least two
 patches, in my view, that *didn't* involve adding SE-Linux-specific
 checks everywhere.  The patch that I reviewed that got thrown out by
 Tom, and the original PGACE framework.  Both of those added alot of
 *hooks*, because they were necessary, but nothing made those hooks
 particularly SELinux-specifc.  We're hearing alot about things being
 SELinux-specific from people who also profess to not know SELinux.
 
 Indeed, as I recall, the patch I reviewed was primairly trying to just
 addess pulling out the hooks necessary for the existing PostgreSQL
 security model.  Very little of it was SE-Linux specific *anything*.
 
 I contend that while the specific hooks which would be added *in
 places that don't already have checks* (in most places, the hook was
 added to replace an existing check) are hooks that then make sense
 for SELinux, they would also make sense for other frameworks.  They
 may also not be a complete list, but once the *framework* is in
 place, adding new hooks (presuming another model would like a hook
 somewhere that SELinux and the existing PG security framework don't)
 should not require some kind of forklift upgrade.
 
  It would be nice
  if it were possible to use the exist permissions-checking functions
  and have them check a few more things while they're at it, but it's
  looking like that won't be feasible, or at least no one's come up with
  a plausible design yet.  
 
 The problem is that the existing permissions-checking is done all over
 the place.  That's not ideal from the get-go, in my opinion.
 Unfortuantely, when we moved all of the permissions-checking to a single
 place, it required knowing about alot of the backend, which Tom took
 exception to.  I agree that's frustrating, but I don't see it as a
 particular reason to throw out the entire concept of a modular security
 framework.  Perhaps we need to better expose just those pieces the
 security framework cares about from the other parts of the backend- it's
 entirely likely that the reason it has to know about everything is that,
 due to where all the existing security checks are, they just (ab)used
 the fact that they had access to that information at hand for that
 object type.
 
  Consequently there are checks spread
  throughout the code, which definitely complicates both validation and
  maintenance.  One question I have is - are the places where those
  checks are placed specific to SE-Linux, or would they be applicable to
  any sort of label-based MAC?
 
 The patch which I worked with Kaigai on was specifically geared to first
 try to get a patch which addressed the existing PG security model in a
 modular way, to allow additional hooks to be added later in places which
 needed them, and to provide the information for other models to make a
 decision about the permission.  I don't feel it was particularly
 SE-Linux specific at all, but rather a first step towards being able to
 support something beyond the model we have today (anything..).
 
   Thanks,
 
   Stephen

I think what makes people think that the changes are SELinux specific is
that the examples given use SELinux contexts. I think it should be made
clear that saying that in the PG there is a database object and we want
to mediate access to create database objects is not SELinux or even MAC
model specific (asside from labels). However to say that a program
labeled myapp_t can connect to the database and create a table and when
its created its labeled mytable_t that would be something SELinux
specific. The framework idea separates that. It says hey here are the
objects in the system and here are the actions on them that we want to
mediate. I will admit that since SELinux is the driving MAC model for
the framework you're going to find that the objects and permissions are
the ones that it wants to control. However like Steven said, adding a
hook later on or having a model not use a hook is not a Herculean task.
We've proven time and time again with the LSM framework that when a
feature is added it is trivial to introduce a new hook to mediate it or
to place an existing hook. I understand that PostgreSQL is a fast moving
target with a large developer base but so is the Linux Kernel and a
similar framework has been working there for years now.

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] Adding support for SE-Linux security

2009-12-08 Thread Peter Eisentraut

On mån, 2009-12-07 at 17:33 +0100, Martijn van Oosterhout wrote:
 On Mon, Dec 07, 2009 at 01:09:59PM -0300, Alvaro Herrera wrote:
   Given the extreme patience and diligence exhibited by KaiGai, I
   hesitate to say this, but it seems to me that this would be
   critically important for the long term success of this feature.  I
   have no idea how much work it would be to make the interface to the
   external security system pluggable, but if it's at all feasible, I
   think it should be done.
  
  This is how the code was developed initially -- the patch was called
  PGACE and SELinux was but the first implementation on top of it.
 
 I find it astonishing that after SE-PgSQL was implemented on top of a
 pluggable system (PGACE) and this system was removed at request of the
 community [1] that at this late phase people are suggesting it needs
 to be added back again. Havn't the goalposts been moved enough times?

PGACE wasn't a plugin system.  It was an API inside the core code.  If
it had been a plugin system, this would have been much easier, because
the plugin itself could have been developed independently.


-- 
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] Adding support for SE-Linux security

2009-12-08 Thread Peter Eisentraut

On mån, 2009-12-07 at 11:45 -0500, Chris Browne wrote:
 I feel about the same way about this as I did about the adding of
 native Windows support; I'm a bit concerned that this could be a
 destabilizing influence.  I was wrong back then; the Windows support
 hasn't had the ill effects I was concerned it might have.

Windows support certainly has had ill effects, but the benefits of
supporting Windows clearly outweigh that.


-- 
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] Adding support for SE-Linux security

On Tue, Dec 8, 2009 at 3:24 PM, Stephen Frost sfr...@snowman.net wrote:
 * Robert Haas (robertmh...@gmail.com) wrote:
 One of the major and fundamental stumbling blocks we've run into is
 that every solution we've looked at so far seems to involve adding
 SE-Linux-specific checks in many places in the code.

 I've really got to take exception to this.  I've only been following
 along and not really participating because, to be honest, I'm frustrated
 with how this has gone down.  In the end there were at least two
 patches, in my view, that *didn't* involve adding SE-Linux-specific
 checks everywhere.  The patch that I reviewed that got thrown out by
 Tom, and the original PGACE framework.  Both of those added alot of
 *hooks*, because they were necessary, but nothing made those hooks
 particularly SELinux-specifc.  We're hearing alot about things being
 SELinux-specific from people who also profess to not know SELinux.

Sorry.  I spent a lot of time for both CommitFest 2008-11 and
CommitFest 2009-07 in the hopes of getting something committable, and
I wasn't successful.  I'm just at the end of my rope.  It seems fairly
clear that Tom isn't going to commit any piece of SE-PostgreSQL at
all, ever.  So who's going to do it?  It doesn't make any sense to
continue trucking along with this patch into the indefinite future if
it has no hope of being committed.

Frankly, I think this comes down to money.  There are several
PostgreSQL companies which employ very capable PostgreSQL committers.
When someone is willing to pony up enough money to get those people
interested (as, I gather, has happened with block-checksumming) then
this will happen.  Until then, I don't believe anyone is going to
volunteer to be responsible for a 10,000-line patch in their free
time.  Tom is the only one crazy enough for that, and he said no.

The next time someone submits a huge, unsolicited patch to do
ANYTHING, we should do them a favor and tell them this up front,
rather than a year and a half later.  Then they could have the
appropriate conversations with the appropriate people and determine
whether to budget for it or give up.  What has happened with this
patch has not served KaiGai well, or improved the image of this
community.

 I agree that's frustrating, but I don't see it as a
 particular reason to throw out the entire concept of a modular security
 framework.

I don't either.  There were certainly technical things in the previous
patch that could stand to have been improved, and I think the general
approach has some potential.

...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] Adding support for SE-Linux security

On Tue, 2009-12-08 at 15:26 -0500, Robert Haas wrote:
[snip...]
 
 I can say from experience that this project is very skeptical of
 frameworks that aren't accompanied by at least one, and preferably
 multiple, working implementations.  So there is a bit of a chicken and
 egg problem here.  What can sometimes work is to say, look, here's a
 place where I can put a hook and later I will do something complex
 with it but here are a couple of relatively simple but useful examples
 to get started.  The examples form the justification for the commit
 because they are independently useful, but they are much simpler than
 what the framework may eventually end up being used for.
 
 I don't believe that this approach is feasible for SE-PostgreSQL.  A
 simple version of label security is still going to be very
 complicated, and there are probably even fewer customers for such a
 thing than there are for SE-PostgreSQL.
 

Ok if it is a chicken and egg problem then we need to find a smaller
egg. I agree that having a huge patch set isn't ideal which is why I
understand the desire to have KaiGai cut back his patches. However the
patches he is putting forward from what I've gathered have no row based
labeling and no MAC enforcement. I can understand if you want to cut
back the object model so you're not mediating every object in the system
but cutting those two features make it unusable by the customers we have
who want to use it. 

  So with regard to confidence in the design I think that part of the
  reason for the skepticism in the fact that it was such a large code
  drop. Even the separated parts were very large.
 
 Definitely true.
 
  I think if the framework
  patches are broken up more logically and in a way that is easier to
  discuss then that might help the community get a grasp on what it is
  trying to accomplish.
 
 Maybe, maybe not.  Nobody's going to commit anything unless it's a
 complete feature.  It can be a cut-down feature, but it has to be of
 independent use.  If there are parts that can be peeled off of
 SE-PostgreSQL and committed independently to some good benefit, then I
 think that's a great idea.  But if it's just a separation of the patch
 for clarity, I don't think there's much value in that.

I don't think it would be just for clarity. I know that not all open
source communities are the same so I'll try to leave the anecdotal
evidence light. When submit patches for the Linux Kernel we take a
single feature and structure them as self contained logical changes.
Separating the changes logically doesn't just improve clarity but also
makes it easy to cherry pick features that can be useful on their own. 
Just because the framework and the SEPostgreSQL features would be two
patch sets doesn't mean they aren't being developed in parallel. It
looks to me that we're in the same boat we were in with SELinux. We had
the feature and proposed it and someone brought up well what about
other security models. So time was spent developing a framework that
everyone could use and as that was being done the SELinux patches were
modified to use this new framework. They were two separate features
developed in tandem. If we do it right the SEPostgreSQL code will be
isolated from the framework and we can spend time putting the framework
in and just plug in the specific security module when time comes. The
X-ACE work went in to X before the corresponding SELinux Flask module
for it and I don't believe LSM and SELinux went into the same merge
window as well.

 
 I have proofread earlier versions of the docs and found them
 inadequate.  There were language issues, but the bigger problem was
 that they were both too specific and yet not sufficiently detailed.
 For example, they'd say install X package on Red Hat.  Well, what if
 I'm not on Red Hat?  The on the other hand they'd say this GUC
 enables mcstrans which means nothing to me.  I think this has been
 improved somewhat in more recent version, but clearly we need (1) good
 developer documentation, so someone other than KaiGai has a chance of
 maintaining the code and keeping it correct as other things are
 changed; (2) user documentation, so that someone can read the feature
 story for this capability; and (3) reference documentation,
 cross-referenced with the user documentation.
 
 Having said that, fixing the documentation won't get this patch
 committed, though it's certainly a step in the right direction.  For
 that we need a committer-owner.
 

True but hopefully proper documentation will help someone decide that
they have enough information to take on that position.

 ...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] Adding support for SE-Linux security

2009-12-08 Thread Tom Lane

Peter Eisentraut pete...@gmx.net writes:
 PGACE wasn't a plugin system.  It was an API inside the core code.  If
 it had been a plugin system, this would have been much easier, because
 the plugin itself could have been developed independently.

Well, it should certainly have used function pointers or something to
allow better pluggability, but that would have been a trivial change.
I don't believe that doing so would have made development any easier.
The real problem in all this is to answer the question do we have the
right hooks in the right places?.  Whether the hooks lead to function
pointers or hard-wired calls doesn't enter into that.  Moreover, since
we can confidently say that all the early answers will be no, it would
be a serious mistake to try to develop the plugin independently.
Having to keep two independent sets of source code in sync would waste
a lot of effort every time you realized you needed to adjust the hook
definitions.  Once you'd gotten to a releasable state maybe you could
assume the hook definitions would become stable, but right now I have no
confidence in that at all.

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] Adding support for SE-Linux security

On Tue, 2009-12-08 at 16:51 -0500, Tom Lane wrote:
 Peter Eisentraut pete...@gmx.net writes:
  PGACE wasn't a plugin system.  It was an API inside the core code.  If
  it had been a plugin system, this would have been much easier, because
  the plugin itself could have been developed independently.
 
 Well, it should certainly have used function pointers or something to
 allow better pluggability, but that would have been a trivial change.
 I don't believe that doing so would have made development any easier.
 The real problem in all this is to answer the question do we have the
 right hooks in the right places?.  Whether the hooks lead to function
 pointers or hard-wired calls doesn't enter into that.  Moreover, since
 we can confidently say that all the early answers will be no, it would
 be a serious mistake to try to develop the plugin independently.
 Having to keep two independent sets of source code in sync would waste
 a lot of effort every time you realized you needed to adjust the hook
 definitions.  Once you'd gotten to a releasable state maybe you could
 assume the hook definitions would become stable, but right now I have no
 confidence in that at all.
 
   regards, tom lane
 

I disagree with several of your statements above. While the question of
whether or not the hooks are in the right place is up for debate what
the hooks should be is something that I think has been explored pretty
well. The hooks should reflect the object model. Where you need to put
them to enforce permission is a different story. 

Also maintaining a module and a framework is not a waste of time. If
your security module has a tremendous code churn when the interface to
the program is modified you should reevaluate your design. Both SELinux
and the Flask X-ACE modules are examples where an existing extension had
a modular framework developed after the fact and easily integrated into
the project. The majority of the work is moving to a framework not
changing function prototypes in code that's already in the framework.

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] Adding support for SE-Linux security

Robert Haas wrote:
 On Tue, Dec 8, 2009 at 10:07 AM, David P. Quigley dpqu...@tycho.nsa.gov 
 wrote:
 I'd be willing to take a look at the framework and see if it really is
 SELinux centric. If it is we can figure out if there is a way to
 accomodate something like SMACK and FMAC. I'd like to hear from someone
 with more extensive experience with Solaris Trusted Extensions about how
 TX would make use of this. I have a feeling it would be similar to the
 way it deals with NFS which is by having the process exist in the global
 zone as a privileged process and then multi-plexes it to the remaining
 zones. That way their getpeercon would get a label derived from the
 zone.
 
 Well, the old patches should still be available in the mailing list
 archives.  Maybe going back and looking at that code would be a good
 place to start.  The non-ripped-out code has been cleaned up a lot
 since then, but at least it's a place to start.

We can see old branches here:

http://code.google.com/p/sepgsql/source/browse/branches/pgsql-8.3.x/sepgsql/src/backend/security/pgaceHooks.c

But I don't provide this framework for the 8.4.x/8.5.x, because this
idea was rejected in the earlier discussion.
Please consider it represent just a concept.

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] Adding support for SE-Linux security

2009-12-08 Thread Bruce Momjian

Robert Haas wrote:
 Sorry.  I spent a lot of time for both CommitFest 2008-11 and
 CommitFest 2009-07 in the hopes of getting something committable, and
 I wasn't successful.  I'm just at the end of my rope.  It seems fairly
 clear that Tom isn't going to commit any piece of SE-PostgreSQL at
 all, ever.  So who's going to do it?  It doesn't make any sense to
 continue trucking along with this patch into the indefinite future if
 it has no hope of being committed.
 
 Frankly, I think this comes down to money.  There are several
 PostgreSQL companies which employ very capable PostgreSQL committers.
 When someone is willing to pony up enough money to get those people
 interested (as, I gather, has happened with block-checksumming) then
 this will happen.  Until then, I don't believe anyone is going to
 volunteer to be responsible for a 10,000-line patch in their free
 time.  Tom is the only one crazy enough for that, and he said no.

I have offered to review/commit the patch.  I don't promise my effort
will be pretty, but I will get the job done.  I have not started yet
because I think we are still unclear if the feature is worth the
additional code maintenance.

I frankly think the patch should be thought of as the SE-Linux-specific
directory files, which KaiGai can maintain, and the other parts, which I
think I can handle.

 The next time someone submits a huge, unsolicited patch to do
 ANYTHING, we should do them a favor and tell them this up front,
 rather than a year and a half later.  Then they could have the
 appropriate conversations with the appropriate people and determine
 whether to budget for it or give up.  What has happened with this
 patch has not served KaiGai well, or improved the image of this
 community.

Yes, this has not been our finest hour.  :-(

I think the causes have been explained already:

o  early patches did not have community buy-in
o  we are unclear about the size of the user community
o  we are unclear what the end user will want
o  the feature is complex
o  the features is in an unfamiliar problem-domain

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] Adding support for SE-Linux security

David P. Quigley wrote:
 So I was reading through a set of slides that KaiGai has and he
 mentioned a May commitfest link and I looked for the comments related to
 his PGACE patches. I've been crawling through the commitfest paces so I
 can figure out what the latest version of the pgace patch is. Does
 anyone know when the patch was reduced to what it is today?

I could salvage a legacy PGACE patch:
  http://sepgsql.googlecode.com/files/sepostgresql-pgace-8.4devel-3-r739.patch

However, its code base was v8.4devel, so conflictable to the latest CVS HEAD.
In addition, it contains various kind of concepts within a single patch.
 * comprehensive security hooks
 * a facility to store security identifier on the header of each row
 * a facility to translate between security identifier (int) and
   security context (text)
 * security_context writable system column support.

From the current perspective, we can understand these features should be
proposed as separated features. But I was young.

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] Adding support for SE-Linux security

2009-12-08 Thread Greg Smith


David P. Quigley wrote:

 I understand that PostgreSQL is a fast moving target with a large developer 
base but so is the Linux Kernel and a
similar framework has been working there for years now.
  


It sounds like how you're thinking about this project's development 
model is inverted from the reality, and it's import to sort that out 
because it really impacts why there's so much resistance here.  One 
reason the Linux kernel moves so fast because they don't care one lick 
for many types of backward compatibility, they'll just change interfaces 
as necessary to work around problems.  To use the terms of the old 2.4 
Linux kernel, there is no stable branch development happens against 
anymore; just the fast changing unstable one, that if everyone is lucky 
eventually converges into some usable versions anyway.


Here, there is zero tolerance for any commit that destabilizes the 
codebase even temporarily.  Until you get the whole thing sorted out 
usefully enough to be shippable quality, you don't go into the main (and 
only official) branch.


Also, the PostgreSQL developers like to deliver a stable release and 
then change *nothing* to it except to fix bugs, supporting that release 
for years.  We consider a released piece of software like a contract to 
the users, and everyone goes through lots of work to avoid changing 
anything unless absolutely necessary.  A very large component of the 
concern here comes from that mindset.  If this goes out, and there's a 
fundamental problem with it, this community doesn't even have a good 
process to fix that until the next major release, around a year later.  
In general, there is no such thing as an upgrade to a stable version 
that includes a serious behavior change.  Having that happen is 
considered a major breakdown in the process, and there's only been a 
very small number of such situations in the past, when some just 
impossible to work around bug was introduced.  Instead, just the 
absolute minimum of changes needed to fix bugs are applied to the 
stable, shipped versions.  If a version ships with a broken enough 
behavior, it's quite possible that fixing it cannot be done in a way 
that can be distributed and applied via the standard minor version 
upgrade procedure used at all.


The idea here is not if it's not quite right, development is fast so it 
will get sorted out eventually.  Instead it's if it's not believed to 
be free of non-trivial bugs, don't commit it at all.  SEPostgres has 
lived in this state for a while now.  And it's not known bugs that are 
the problem, it's that almost all of the Postgres community can't even 
accurately gauge whether there are bugs or not in the code/design, which 
is really uncomfortable given how things work here.


--
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] Adding support for SE-Linux security

David P. Quigley wrote:
 On Tue, 2009-12-08 at 15:26 -0500, Robert Haas wrote:
 [snip...]
 I can say from experience that this project is very skeptical of
 frameworks that aren't accompanied by at least one, and preferably
 multiple, working implementations.  So there is a bit of a chicken and
 egg problem here.  What can sometimes work is to say, look, here's a
 place where I can put a hook and later I will do something complex
 with it but here are a couple of relatively simple but useful examples
 to get started.  The examples form the justification for the commit
 because they are independently useful, but they are much simpler than
 what the framework may eventually end up being used for.

 I don't believe that this approach is feasible for SE-PostgreSQL.  A
 simple version of label security is still going to be very
 complicated, and there are probably even fewer customers for such a
 thing than there are for SE-PostgreSQL.

 
 Ok if it is a chicken and egg problem then we need to find a smaller
 egg. I agree that having a huge patch set isn't ideal which is why I
 understand the desire to have KaiGai cut back his patches. However the
 patches he is putting forward from what I've gathered have no row based
 labeling and no MAC enforcement. I can understand if you want to cut
 back the object model so you're not mediating every object in the system
 but cutting those two features make it unusable by the customers we have
 who want to use it. 

The coverage of access controls are tradeoff between amount of the
changeset and valuable functionalities, in generally. Ultimately it
is a role of developer to decide what is unseparatable core feture
and what is separatable secondary one.

It is my decision to restrict types of database objects to reduce
burden of reviewers, so the latest one apply SELinux specific access
controls on only databases, schemas, tables and columns.

Even if we have a framework to host label-based MAC, its coverage shall
be unchanged, because comprehensive support at once obviously makes
harder to review.

 So with regard to confidence in the design I think that part of the
 reason for the skepticism in the fact that it was such a large code
 drop. Even the separated parts were very large.
 Definitely true.

 I think if the framework
 patches are broken up more logically and in a way that is easier to
 discuss then that might help the community get a grasp on what it is
 trying to accomplish.
 Maybe, maybe not.  Nobody's going to commit anything unless it's a
 complete feature.  It can be a cut-down feature, but it has to be of
 independent use.  If there are parts that can be peeled off of
 SE-PostgreSQL and committed independently to some good benefit, then I
 think that's a great idea.  But if it's just a separation of the patch
 for clarity, I don't think there's much value in that.
 
 I don't think it would be just for clarity. I know that not all open
 source communities are the same so I'll try to leave the anecdotal
 evidence light. When submit patches for the Linux Kernel we take a
 single feature and structure them as self contained logical changes.
 Separating the changes logically doesn't just improve clarity but also
 makes it easy to cherry pick features that can be useful on their own. 
 Just because the framework and the SEPostgreSQL features would be two
 patch sets doesn't mean they aren't being developed in parallel. It
 looks to me that we're in the same boat we were in with SELinux. We had
 the feature and proposed it and someone brought up well what about
 other security models. So time was spent developing a framework that
 everyone could use and as that was being done the SELinux patches were
 modified to use this new framework. They were two separate features
 developed in tandem. If we do it right the SEPostgreSQL code will be
 isolated from the framework and we can spend time putting the framework
 in and just plug in the specific security module when time comes. The
 X-ACE work went in to X before the corresponding SELinux Flask module
 for it and I don't believe LSM and SELinux went into the same merge
 window as well.

It is necessary to deploy the framework and SELinux support at same time
or the framework earlier than SELinux? We can organize a common framework
when the second security module will come in. From our experience, it may
need similar security hooks on same or similar strategic points.

In the development history, the code size and complexity had been a matter
for inclusion. I also think the idea to invoke security modules via mac
framework is right approach, but it increases the initial code size compared
to the current approach in spite of even user visible whorth.


 I have proofread earlier versions of the docs and found them
 inadequate.  There were language issues, but the bigger problem was
 that they were both too specific and yet not sufficiently detailed.
 For example, they'd say install X package on Red Hat.  Well, what if

Re: [HACKERS] Adding support for SE-Linux security

2009-12-08 Thread Magnus Hagander

2009/12/9 Bruce Momjian br...@momjian.us:
 I frankly think the patch should be thought of as the SE-Linux-specific
 directory files, which KaiGai can maintain, and the other parts, which I
 think I can handle.

I think that's a horribly bad idea.

We have already got a similar issue with ECPG, which clearly stagnates
whenever Michael is busy and don't have time to go through the
patches. Because it's his code, and nobody else knows how to and/or
cares to maintain it. And this is just a single piece of the frontend
that doesn't affect anything else.

If you want to do something similar for sepg, then sepg needs to be
turned into a full plugin system, where the plugin is a completely
separate thing. In which case the plugin can be developed separately,
for example on pgfoundry (and be considered to merge later, if we
want, but not necessarily ever since it has a narrow user base).

I haven't looked at the patch properly for quite a while, but I
imagine turning it into such a plugin is not feasible. Because if it
is, why haven't this been done already? :) But if it is, perhaps that
is something we should consider, since it lessens the maintenance
burden into just the API (which is still a huge burden compared to
many of our APIs, but it is a lot less than what the patch is now)

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.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] Adding support for SE-Linux security