Re: 8.4 release planning

On 1/27/09 6:57 PM, "Greg Smith" <gsmith(at)gregsmith(dot)com> wrote:

> On Tue, 27 Jan 2009, Chad Sellers wrote:
>
>> I'll speak to this a bit (Josh is also a Tresys employee). I can't say who
>> my customers are, but I can speak to their needs. They really need row-level
>> mandatory access controls (so both).
>
> From the perspective of what this would buy as far as this feature being a
> PostgreSQL advocacy point, one of the questions Tom asked about a bit
> upthread is still a bit hazy here. There are commercial database
> offerings selling into the "trusted" space already. While the use-cases
> you describe make perfect sense, I don't think it's clear to everyone yet
> if there's a unique draw to a PostgreSQL + selinux solution that the class
> of customers you're talking about would prefer it to purchasing one of
> those products. Is the cost savings the main driver here, or is there
> something else about a secure LAPP stack that makes it particularly
> compelling?
>
Cost savings may be a driver, but it's certainly not the main driver. A
problem with the current systems (e.g. Oracle) is that they largely operate
in their own world. Oracle Label Security labels do not extend outside the
database to the rest of the system, which makes it impossible to build
certain things. For instance, you can't really build a trusted LAPP stack.
With SE-PostgreSQL, the label used for access control is bound by the kernel
and used by it and the other components of the stack (apache, PostgreSQL).
We can even extend all the way to the end system using labeled IPSec.

Another major drawback to the currently available trusted databases is that
they have hard-coded policy rules rather than flexible ones. While these
hard-coded rules may be appropriate in some scenarios, they often end up
being impractical. For instance, any sort of pipeline (like that of my
example 3) is difficult if not impossible to implement on most of these
hard-coded systems. Additionally, changing the label in most of these
systems requires a privilege that lets you bypass the policy rules, while a
flexible Type Enforcement system (like SE-PostgreSQL) allows you to specify
exactly how relabels should be allowed within the policy.

I'll be happy to provide more details where required. Hopefully that
provided a little light.

Thanks,
Chad Sellers