On Fri, 2009-12-11 at 09:20 -0500, Robert Haas wrote:
> On Fri, Dec 11, 2009 at 4:31 AM, Magnus Hagander <magnus@hagander.net> wrote:
> > On Fri, Dec 11, 2009 at 05:45, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Robert Haas <robertmhaas@gmail.com> writes:
> >>> On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane <tgl@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.7090806@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
