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@[EMAIL PROTECTED]
http://www.gregsmith.com
Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
|
