On 1/27/09 4:40 PM, "Ron Mayer" <rm...@cheapcomplexdevices.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers