Greg Stark wrote:
> On Tue, Jul 21, 2009 at 3:20 PM, Joshua Brindle<method@manicmethod.com> wrote:
>> Backing up from KaiGai's description a bit, basically what this is needed
>> for is storing multilevel data in a single db instance.
>>
>> For example, you have people logging in from different classifications
>> (unclass, secret, top secret, etc) and the data they put in is marked
>> (labeled) with their classification label.
>>
>
>
> I'm beginning to wonder if we haven't gone about this all wrong. Every
> time someone asks my question about use cases the only answers that
> come back are about row-level security. Perhaps that's the only case
> that really matters here.
>
> If we provide a way to control access to database objects through
> SELinux policies -- ie, one which is functionally equivalent to what
> we have today but just allows administrators to control it in the same
> place they control other SELinux system privileges, is that useful? Is
> that something SE administrators want? Or are they happy to use
> Postgres roles and grants and just want the finer row-level data
> access controls?
>
No, for multiple reasons. First a single person (role) could be logging in at
different levels (eg., running the same application as the same linux user with
the same credentials) and would need to see different things from the database.
The SELinux contexts would provide the differentiation in this case and the
SELinux policy would enforce the multilevel policy.
I also don't think your roles and grants could enforce a multilevel policy but
that is something I'd have to look into deeper to know for sure. Also the
objects need to be labeled based on how they were inserted, and 're-grading'
applications need to be able to relabel them. You still need the 'read-down'
behavior I talked about above.
You also snipped the other scenario I had where row based access control isn't
required but column level and stored procedure level are. I understand you
already have column level access controls but it still goes back to how the user
is accessing the data, as a top secret user who can read the column with full
precision or as a secret user with precision removed via a trusted stored
procedure. The SELinux policy would have to give the stored procedure the
ability to read the column and trust it to remove the necessary amount of precision.