On Tue, 6 May 2008, Tom Lane wrote:
And of course the next question after that is why we should want to depend on SELinux at all, rather than implementing row filtering in the framework of SQL permissions...
It may be the case that clean row and column filtering at the SQL layer are pre-requisites for a clean SELinux implementation, where the only difference is that the permission checks are handled by asking SELinux instead of looking in the catalog.
As for why SQL restrictions alone aren't enough...the simple answer is because it's not SELinux, which I say in all seriousness because it is turning into a requirement in some places.
SELinux lets you control what a user login is capable of no matter what application they run, and managing those capabilities can happen in one place--the SELinux tools. There's lots of ways to address OS login problems. Let's say the logins have a PAM plug-in that restrict what you can login to based on what machine you're on, and also require one of those randomly generating key cards so that you can't steal someone else's username/password. If you've got a scheme like that, and the database enforces SELinux restrictions, it doesn't matter whether your DBA followed all the PostgreSQL security rules correctly, as long as they got the SELinux mapping part right. And you don't have to make sure whatever custom security mechanism you've integrated into the login or post-login process is recognized by the database proper at all, as long as the restrictions can be mapped to the SELinux+database space.
Simple example of something hard to replicate without this framework: you discover someone is a rat. You update your list of active users and push that to all your servers. Now even if said rat is already logged into the database server and busy doing 'psql -o /disk/usbkey -c "select * from secretdata"' you just cut them off in the middle of the query--without needing to find all the database servers and execute "alter table secretdata set ...", just by doing simple user account maintenance the way people are already comfortable with and have procedures for.
That's the basic idea here--put the authorization into one layer where it's easy (for some definitions of "easy") to manage and extensible as needed, without having to touch the individual applications directly, just by adjusting what permissions you publish when data is requested. I'm sure someone can raise issues or suggest alternate implemenations for my specific examples, but much like other privledge escalation defense mechanisms these environments look for redundant layers of security. In reality users of this would aim for a completely locked down base PostgreSQL *and* a completely locked down SELinux implementation integrated into that, reinforcing one another, rather than just relying on one level of security.
-- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
