| |||||||||||||
SELinux and PostgreSQL: a worthwhile union?SELinux and PostgreSQL: a worthwhile union?Posted Dec 4, 2009 22:44 UTC (Fri) by dlang (✭ supporter ✭, #313)Parent article: SELinux and PostgreSQL: a worthwhile union?
this is a useful feature to get into postgres, even if nobody uses it in production.
the reason is that Oracle offers a similar capability, and checkbox management frequently sees such things as significant, even if they don't end up using them (after all, they may need to do more in the future and use it, so if postgres doesn't do this and oracle does they should stick with oracle)
personally, i don't believe that trying to do this level of permissions inside the database is appropriate. I believe that if you are this worried about your data you should not give the applications direct access to the database, they should talk to a shim layer that is small and can be tested to only generate expected queries to the database.
(Log in to post comments)
Why? Posted Dec 5, 2009 1:33 UTC (Sat) by gbutler69 (guest, #54063) [Link]
Why do you think a shim is better? Why don't you think database roles, schema, table, column,
and row permissions/restrictions are good/better?
Why? Posted Dec 5, 2009 4:07 UTC (Sat) by cetialphav (subscriber, #22533) [Link]
Indeed, it isn't obvious to me that shims are a better solution as there are some serious downsides. A shim is much less flexible and may need to be changed (and have its security audited) every time the application needs to change how it accesses the database. It also becomes an attack vector. If an application can coopt the shim, then it has full access to the database.
I can see where there could be some interesting usage for the integration of databases and SELinux. Many organizations have a centralized database storing everything, yet few departments actually should be able to see the whole thing. I am thinking of something like a medical institution where the people doing the billing need to know what I owe, but don't need my medical history. Of course, databases already offer ways to limit what certain users see, but security people don't have a centralized way to set these policies.
This kind of integration is one step towards giving administrators one centralized place to set the security policy and I think that offers a lot of benefits. The difficulty of writing these policies in SELinux is an issue, but I can see where companies like IBM would be happy to offer this as a consulting service.
Why? Posted Dec 10, 2009 14:00 UTC (Thu) by Baylink (subscriber, #755) [Link]
> A shim is much less flexible and may need to be changed (and have its security audited) every time the application needs to change how it accesses the database.
Correct.
But that's not a bug, it's a feature!<tm>
A shim can be expected, generally, to be *much* smaller than the code on either side of it -- by 2 or 3 orders of magnitude if not more, unless someone's done something horribly wrong -- and should therefore be *much* easier to prove correct.
Why? Posted Dec 5, 2009 4:26 UTC (Sat) by SEJeff (subscriber, #51588) [Link]
Search for the arguments on Discretionary Access Control (DAC) vs Mandatory Access Control (MAC).
Why? Posted Dec 6, 2009 2:00 UTC (Sun) by flewellyn (subscriber, #5047) [Link]
PostgreSQL's role-based access controls do not neatly fall into either category.
SELinux and PostgreSQL: a worthwhile union? Posted Dec 6, 2009 1:42 UTC (Sun) by dfetter (guest, #40012) [Link]
I only see a benefit in the proprietary forks. The checkboxers can always find (or create) a checkbox that the community version doesn't have, and trying to dance their dance for its own sake is fruitless.
|
|||||||||||||