* Kenneth Downs (ken@secdat.com) wrote:
> We use real database users in our systems, we don't connect in with an
> over-endowed user and then arbitrate security in client code.
> Therefore, we depend entirely upon the server's ability to enforce security.
We do the same thing. :)
> The practical advantage of this, which is huge, is that nowhere in my
> Postgres settings do I have to make allowance for the web user (apache)
> to "go root" with respect to Postgres. As a general rule we consider
> this good of course, because a remote exploit on the web server could
> not do anything the user could not do anyway.
Right, exactly.
> Except for the hole. On a public site that lets users register, we have
> to have way to let the web server assume the role of somebody who has
> createuser privelege, and that's pretty much the end of the no-root
> policy. If an exploit could be placed, it could simply go into that
> mode and create a superuser.
Thankfully we don't have any systems with this requirement. :) But, a
possible solution might be to create an OOB mechanism by which you can
only pass a username/pw/whatever is needed to create a user. ie: dump
it into a file that's checked using cron or something like that. Then
another process (the cronjob, or what have you) is privileged and can
create the user on your behalf. You have to be very careful in
programming the privleged job but ideally the worst an attacker could do
would be to create additional users within whatever the normal
constraints are (which, theoretically, is something they can do from the
website *anyway*).
> What would be really nice is if you could limit the ability of
> CREATEUSER to grant roles. A nice general solution would be to allow a
> user with CREATEUSER privelege to only put other users into the same
> groups that person is in, or perhaps into a list specified by a
> higher-privelege user.
>
> What's chances of anything like that showing up?
Honestly, I think the above approach would be better than having
something in the database to try and do that...
Thanks,
Stephen