Re: [PATCH] SE-PgSQL/tiny rev.2193 - Mailing list pgsql-hackers

<br /><br /> Greg Stark wrote: <blockquote cite="mid:407d949e0907211538wb1e5cc5gbf65b8d085c9684@mail.gmail.com"
type="cite"><prewrap="">On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindle<a class="moz-txt-link-rfc2396E"
href="mailto:method@manicmethod.com"><method@manicmethod.com></a>wrote: </pre><blockquote type="cite"><pre
wrap="">Youalso snipped the other scenario I had where row based access control
 
isn't required but column level and stored procedure level are.   </pre></blockquote><pre wrap="">
Well we already have column level and stored procedure privileges.
 </pre><blockquote type="cite"><pre wrap="">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.   </pre></blockquote><pre wrap="">
Sure, and people do this every day already with postgres roles and privileges.
 </pre><blockquote type="cite"><pre wrap="">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.   </pre></blockquote><pre wrap="">
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.
 </pre></blockquote><br /> I don't understand how you came to this conclusion. Quoting from my prior email:<br /><br />
""No,for multiple reasons. First a single person (role) could be logging in at different levels (eg., running the same
applicationas the same linux user with the same credentials) and would need to see different things from the database.
TheSELinux contexts would provide the differentiation in this case and the SELinux policy would enforce the multilevel
policy.""<br /><br /> In this case the selinux context (which specifies their MLS level) says the user is running at
unclassand there should be no possible credentials or role or anything that gives him access to data above unclass in
thedatabase. This _is_ a unification of the policy because whether the unclass user is accessing files or rows in a
mixed-leveldatabase or entire databases that are classified as such the SELinux policy is governing that. <br /><br />
Itsthe same with selinux aware X. If a user is running 2 database clients, one at unclass and one at secret then each
applicationwould how the appropriate results. The policy also disallows that user from copying from the secret database
clientinto the unclass client (in this case there are SELinux rules enforcing behavior of X apps, of the database
clientsand of the filesystem), unified indeed.<br />