Re: Disable databse listing for non-superuser (\l) ?

Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
>
> On Sat, Jul 25, 2009 at 5:23 AM, Bill Moran<wmoran(at)potentialtech(dot)com> wrote:
> > Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> >>
> >> On Fri, Jul 24, 2009 at 5:02 PM, Brian A.
> >> Seklecki<lavalamp(at)spiritual-machines(dot)org> wrote:
> >> > All:
> >> >
> >> > Any suggestions on how-to, or comments on a potential NFR, to disable
> >> > non-superuser's from viewing the database list via \l?
> >>
> >> So, is this a misguided attempt at security through obscurity, or are
> >> you looking at limiting the noise that users see when they look at
> >> databases?
> >
> > I don't know about misguided, Scott.  Security takes many forms.
> >
> > If a client wants shared database hosting, but wants an assurance that
> > other clients using the same shared DB server can't tell who else is
> > using it?
>
> Then they want something other than security. Which isn't necessarily
> a bad thing, just don't fool yourself into thinking it's security.

To be fair, the OP didn't say it was for security purposes.

> > It's not security in the strict computer-science definition.  Obviously,
> > if the proper ownerships and grants don't exist to protect the data, in
> > addition to said obscurity, then the whole thing is pointless.
>
> exactly.
>
> >  But such
> > obscurity _in_addition_ to proper, real security, has show usefulness
> > in many areas.
>
> Citation needed. I doubt it's ever made any real measurable difference.

Well, I did mention one -- the ssh example below.

> > Take a properly secured SSH server, for example, and move it to an obscure
> > port #.  Now you've reduced the number of mindless bots looking for
> > unprotected root accounts, and your IDS solution that monitors the ssh
> > logs is actually useful.  Of course, that's only effective if ssh is
> > properly secured to begin with.
>
> If it's secure, then it doesn't matter what port it's on. If it's not
> secure, being on a secondary port is no great improvement.

I'm surprised how it seems that very few people are familiar with IDS
and auditing functions.

If you have an IDS or need to audit suspicious activity as part of your
security posture (which we _do_ and everyone _should_) then anything you
can do to reduce the amount of false positives (i.e. "noise") coming through
the IDS or audit system, makes your IDS/audit process more efficient. And
with a more efficient audit process, you're more likely to identify real
threats, thus your system is more secure.

> > Many clients want the cost-effectiveness of shared DB hosting.  Many of
> > them also want it kept under wraps that they're doing so.  The provider
> > that can do such a thing gets the contract.  Those that complain about
> > "it's not security, it's obscurity" do not get the contract.
>
> Yep. And i can guarantee that having such a contract mens you've got
> a customer that makes you wanna pull your hair out. Having dealt with
> a few like that in the past. :)

How many clients do you have that don't result in hair pulling? If it
were easy, it'd be difficult to get paid for it.

> But my very serious point on this is that postgresql isnt' designed to
> hide such things from users, and changing it to do so takes a lot of
> effort for no real return on investment. OTOH, having a psql client
> that just uses a different set of queries so that it doesn't show the
> other dbs could be actually useful and take little or no effort.
> Given the lack of a serious clarification or answer from OP, I've not
> been inclined to post anymore on this subject.

I work with the OP, and his post was the result of discussions we had
earlier this week on how we can take our security posture to the next
level. I warned him about asking this on the list ... knowing that the
assumption would be that we're doing this as a substitute for real
security. The reality is that we've implemented all the other standard
methods, this is the result of our continual effort to find ways to lock
things down even tighter.

--
Bill Moran
http://www.potentialtech.com