Thread: Disable databse listing for non-superuser (\l) ?
All: Any suggestions on how-to, or comments on a potential NFR, to disable non-superuser's from viewing the database list via \l? Possibly a postgresql.conf toggle or restrictions on the internal views that constitute ....say, 'pg_catalog.pg_database'. Something equivalent, in principal, to FreeBSD sysctl: % security.bsd.see_other_uids=0 Just a thought... ~BAS
On Fri, Jul 24, 2009 at 5:02 PM, Brian A. Seklecki<lavalamp@spiritual-machines.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? If it's for security through obscurity, I don't have any real advice, as any changes to do that in a manner that really limits the ability of the user to look up that data are likely to have unintended negative consequences. OTOH, if you just want to limit what folks see to make their life easier, then I'd suggest making the changes in psql and change the queries it uses to look up the databases the user has access to.
> 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? The answer to that question would be "yes". ~BAS
Scott Marlowe <scott.marlowe@gmail.com> wrote: > > On Fri, Jul 24, 2009 at 5:02 PM, Brian A. > Seklecki<lavalamp@spiritual-machines.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? 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. But such obscurity _in_addition_ to proper, real security, has show usefulness in many areas. 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. Similar concept. 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. I mean, didn't Apple just kill someone for letting their new iPhone design leak? -- Bill Moran http://www.potentialtech.com
Bill Moran schrieb: > Scott Marlowe <scott.marlowe@gmail.com> wrote: >> On Fri, Jul 24, 2009 at 5:02 PM, Brian A. >> Seklecki<lavalamp@spiritual-machines.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? > > 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. But such > obscurity _in_addition_ to proper, real security, has show usefulness > in many areas. > > 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. > > Similar concept. > > 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. > > I mean, didn't Apple just kill someone for letting their new iPhone > design leak? this is now going off topic - but what do you mean with your last sentence? Cheers Andy
On Sat, Jul 25, 2009 at 2:53 PM, Andreas Wenk<a.wenk@netzmeister-st-pauli.de> wrote: >> I mean, didn't Apple just kill someone for letting their new iPhone >> design leak? > > this is now going off topic - but what do you mean with your last sentence? Please don't quote an entire message if you're only responding to part of it. (That's what people are really talking about when they say top-posting is bad.) see: http://www.theregister.co.uk/2009/07/22/security_offical_suspended/ I don't think there's any actual indication that Apple was involved directly. -- greg http://mit.edu/~gsstark/resume.pdf
Greg Stark schrieb: > On Sat, Jul 25, 2009 at 2:53 PM, Andreas > Wenk<a.wenk@netzmeister-st-pauli.de> wrote: >>> I mean, didn't Apple just kill someone for letting their new iPhone >>> design leak? >> this is now going off topic - but what do you mean with your last sentence? > > Please don't quote an entire message if you're only responding to part > of it. (That's what people are really talking about when they say > top-posting is bad.) > > see: > http://www.theregister.co.uk/2009/07/22/security_offical_suspended/ > > I don't think there's any actual indication that Apple was involved directly. > no problem and got it - but my reply was kind of a quick shot because I don't think that posting messages /sentences like that are really useful or helpful for the community ... Bill, don't get me wrong - this is my personal opinion. Cheers Andy
On Sat, Jul 25, 2009 at 5:23 AM, Bill Moran<wmoran@potentialtech.com> wrote: > Scott Marlowe <scott.marlowe@gmail.com> wrote: >> >> On Fri, Jul 24, 2009 at 5:02 PM, Brian A. >> Seklecki<lavalamp@spiritual-machines.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. > 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. > 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. > 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. :) 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.
Scott Marlowe <scott.marlowe@gmail.com> wrote: > > On Sat, Jul 25, 2009 at 5:23 AM, Bill Moran<wmoran@potentialtech.com> wrote: > > Scott Marlowe <scott.marlowe@gmail.com> wrote: > >> > >> On Fri, Jul 24, 2009 at 5:02 PM, Brian A. > >> Seklecki<lavalamp@spiritual-machines.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