Re: [0/4] Proposal of SE-PostgreSQL patches - Mailing list pgsql-hackers

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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD