Greg Stark wrote:
> On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindle<method@manicmethod.com> wrote:
>> You also snipped the other scenario I had where row based access control
>> isn't required but column level and stored procedure level are.
>
> Well we already have column level and stored procedure privileges.
>
>> 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.
>
> Sure, and people do this every day already with postgres roles and privileges.
>
>> 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.
>
> Well the question is: Is the important feature of SEPostgres the
> unification of the privilege model with every other piece of the
> system in the SELinux policy? Or is that not the main thing and only
> the row-level access security is interesting. None of the use cases
> seem to put any emphasis on the unification of the security policy.
It is the most significant feature of SE-PostgreSQL to enforce the
centralized security policy, as if SELinux enforces its policy to
the accesses on objects manged by operating system.
Indeed, SELinux can control accesses on user's data stored within
filesystems (operating system feature) based on its security policy.
However, nowadays, filesystem is not only piece to store user's data
with variable credentials (ie; secret, unclassified, ...).
Needless to say, database is a significant pieces to store variable
user's data, but it is not invisible from the operating system how
does it controled, because all the database objects are managed in
userspace. It means SELinux cannot control data flows via databases,
although it occupies an important place in our information system.
Granularity in access controls is an independent issue.
Integration of the access control policy is an issue how to decide
whether the required accesses to be allowed, or not.
On the other hand, table/column/row level access control is an issue
what objects to be controled.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
