Re: 8.4 release planning - Mailing list pgsql-hackers
From | Joshua Brindle |
---|---|
Subject | Re: 8.4 release planning |
Date | |
Msg-id | 497F6480.5010206@manicmethod.com Whole thread Raw |
In response to | Re: 8.4 release planning (Ron Mayer <rm_pg@cheapcomplexdevices.com>) |
List | pgsql-hackers |
Ron Mayer wrote: > Stephen Frost wrote: >> * Gregory Stark (stark@enterprisedb.com) wrote: >>> It does seem weird to simply omit records rather than throw an error and >>> require the user to use a where clause, even if it's something like WHERE >>> pg_accessible(tab). >> It is weird from an SQL perspective, I agree with you there. On the >> other hand, it's what the security community is looking for, and is >> what's implemented by other databases (Oracle, SQL Server...) that >> do row-level security and security labels. Requiring a where clause >> or you throw an error would certainly make porting applications that >> depend on that mechanism somewhat difficult, and doesn't really seem >> like it'd gain you all that much... > > > It seems to me that there are two different standards to which this feature > might be held. > > Is the goal > > a) SEPostgres can provide useful rules to add security to some > specific applications so long as you're careful to avoid crafting > policies that produce bizarre behaviors (like avoiding restricing > access to foreign key data you might need). On the other hand it > gives you enough rope to hang yourself and produce weird results > that don't make sense from a SQL standard point of view if you > aren't careful matching the SEPostgres rules with your apps. > This is what we like to call a flexible mandatory access control system, such as type enforcement. Give everything a type, write rules around the types. If you mess up your system may not boot (or your database queries might be strange). In talking to KaiGai the rules should not allow you to create inconsistencies, however. If you delete a row with a foreign key constraint and you cannot delete the associated row in another table the whole operation should fail. We want to fail on the side of maintaining data integrity and consistency while still allowing you enough rope to have a fine grained, flexible access control system. > or > > b) SEPostgreSQL should only give enough rope that you can not > craft rules that produce unexpected behavior from a SQL point > of view; and that it would be bad if one can produce SEPostgres > policies that produce unexpected SQL behavior. SELinux (and associated security aware applications) tend to go the way of very fine grained and let the policy author decide how to use it. I've seen SELinux policies with as few as 3 types, to as many as 3000. It is up to the policy author to choose the granularity appropriate for their purpose. I'd hate to see arbitrary limits put on the policy because of applications that might now operate correctly if they get an unexpected error (the applications should be fixed, not the security policy crippled) > > It seems to me many of the security-enhanced products seem to > do the former; while it seems some of the objections to this > patch are more of the latter. > Historically trusted systems were fairly course grained, with only Bell and LaPadula policies[1]. SELinux is probably the first fine grained mandatory access control system in the mainstream. 1 http://en.wikipedia.org/wiki/Bell-LaPadula_model
pgsql-hackers by date: