Re: How to get SE-PostgreSQL acceptable

> However, we have to make clear whether the PGACE architecture
> is incorrect, or not, at first.
> I think the name of PGACE is not important, but it is necessary
> to make SELinux's decision in similar strategic point in finally.

I've been thinking about this issue as well. I think a framework of
some kind could be acceptable, but only if we're convinced that the
framework is really general enough to handle all of the cases that we
care about. For example, can we back-port our existing DAC
infrastructure to use PGACE? Is it really true that SE-PostgreSQL
interacts through the rest of the system ONLY through PGACE? If the
answers to both questions are YES, then it's a framework. If the
answer to either question is NO, then it's just a bunch of places
where you needed to stick code to make SE-PostgreSQL work.

I haven't read the code, but from reading the docs, I have a feeling
that right now the answer to both questions are NO, which means it
doesn't really have a lot of value. One example of this is the
pg_security system catalog. The catalog representation you're
proposing is probably just fine for associating OIDs to SELinux
security labels. But trying to present it as a general thing that
some other security implementation could reuse just doesn't seem
realistic. Who is to say that the next person who writes an enhanced
security feature will want to use text as the representation for their
security domains? It could just as easily be two integers, or an
array of booleans. This is after all a database product, so the
chances that someone would want to do something with structured data
seem non-negligible.

In the end, you're going to have to be the one who makes the decision
on which way to go. In some ways, I think that a plugin architecture
would be better for everyone: we worry about the things on our side of
the abstraction boundary, and you worry about the things on your side.
Potentially you or someone else can release enhanced security plugins
without needing any changes to core, and potentially on a different
release cycle. On the other hand, a plugin architecture is probably
going to be a lot of work. It seems that to install the plugin you
would need to make system catalog changes as well as stuff additional
system attributes into every table, which are relatively invasive
changes. And you'll need to convince everyone that it's really a
plug-in architecture and not just a special case for SE-PostgreSQL, so
you'll need to prove that there are multiple viable clients, perhaps
by backporting our existing DAC.

...Robert