Re: 8.4 release planning

On 1/27/09 4:40 PM, "Ron Mayer" <rm_pg(at)cheapcomplexdevices(dot)com> wrote:

> Joshua Brindle wrote:
>>> FWIW, as you know, sepostgresql is already included in Fedora. You can
>>> continue shipping it as a seperate RPM set.
>>
>> That is non-ideal. Getting the capability in to the standard database
>> shipped with RHEL is very important to me and my customers.
>
> Could you speak - even in general terms - about who your customers are
> and what kinds of needs (is row-level acls the most important to them?
> mandantory access control at the table level? both?) they have?
>
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). I'll give a few examples that will
hopefully help here.

1) One customer had several networks, each with a different classification.
When a user needed to find anything, it was very painful as they would have
to log into each network one at a time to search for anything. What they
wanted to do was have a trusted database with a combined index of all the
networks. They wanted to be able to write a flexible policy that could grant
access to individual entries in the database based on what network the
request came from in addition to the security clearance of the user
requesting data.

2) Another example that we've been asked for repeatedly but had to turn away
as the capability did not yet exist is a trusted LAMP/LAPP stack (Note that
KaiGai is also working on the apache portion of this to provide a complete
trusted LAPP stack). Under this model, individual web scripts can be run
with a specific type. Combined with an SE-PostgreSQL policy, this gives the
ability to restrict what a specific script can access. Additionally, as
SE-PostgreSQL ties back in to the operating system mandatory access control
mechanism, we can tie the type of the script back to the type of the actual
user making the request. Coupled with labeled IPSec, this means we can
control access to data in the database based on the clearance or role (or
anything else you want to represent in their type) of the user on their end
system.

3) A customer wanted to implement an approval process that required several
steps. Without SE-PostgreSQL, we were forced to implement this by making
lots of copies. Stage 1 would approve the package and copy it into Stage 2's
inbox. We would grant each stage write access to the next stage's inbox in
order to enforce information flow. This was very expensive, and didn't scale
well. With SE-PostgreSQL, we could leave the data where it was and simply
relabel the row(s). Each stage would be granted the ability to relabel from
its type to the type of the next stage. No copies are necessary.

I hope those help. I realize that many of you may not be used to dealing
with customers who have such stringent security requirements, but if
SE-PostgreSQL gets merged, that could change.

Thanks,
Chad Sellers