I would be wary about trusting all connections from localhost. As vulnerabilities are many, getting a local unprivileged shell isn't exactly hard and as opening a socket connection isn't exactly a privileged operation.. you could expose yourself to a nasty bootstrap attack. Probably better to trust the local unix domain socket, and make it accessible by root only... if you really need it.
You make a good point. Conversely, a part of basic security policies is to present as little attack surface as possible. Ensuring that you're not trusting local connections with root equivalent access to your database is a good way of doing that. Modern GNU/Linux distributions have many thousands of packages installed, some of which with fairly open Internet access. Could you put up a default deny firewall to prevent that? Yes. Given that, in most systems there will always be holes punched in those firewalls which allow attacks through as those machines are typically used to serve traffic and do actual work. If you are exploited by a vulnerability in some random package you have installed then you /will/ have potentially multiple /untrusted/ and /hostile/ users on your system. Now, assuming there isn't a local privilege escalation attack to which your kernel is vulnerable, they'll be looking for services which treat local sockets as trusted and attempt to bootstrap from there. A vital concept of basic security precautions is that one doesn't just prevent attacks through secure defaults and front-line security precautions (i.e. firewalls), but one must both contain and detect successful penetrations when they do occur. You must have defence in depth, and not just a hard shell of security, because you can never really tell which one of those protective safeguards will fail due to bugs, human error, or technical incompetence.
I believe the null hypothesis should be that you assume there are vulnerabilities in those systems. Your assertion that it's extremely unlikely that local privilege escalations exist is demonstrably false. In fact a quick query of the CVE database shows a large number of /known/ vulnerabilities ( http://web.nvd.nist.gov/view/vuln/search-results?cves=true&#... ). Regarding the statement that if you can't trust localhost then your defences have failed... well, duh. The point is to limit the damage by having multiple layers of defence. If a script kiddie manages to use UltraPWN2000 to get an unprivileged shell on your box, you don't want them to be able to easily just drop all tables if they're not smart enough to use a local privilege escalation (assuming they can compile locally anyway). You won't be able to prevent all damage from a skilled attacker but you should attempt to mitigate it and give yourself time to respond to it. You don't trust your locked front door to protect your valuables, you put them in a safe.
Your assertion that it's extremely unlikely that local privilege escalations exist
You misread me. I meant the opposite.
Your argument was based on the premise "assuming there isn't a local privilege escalation attack to which your kernel is vulnerable". I said this premise is invalid (as you just confirmed yourself).
You don't trust your locked front door to protect your valuables, you put them in a safe.
The front door is your firewall. The safe is your host. When someone breaks into your host then it's game over. When you have too much spare time you can attempt to layer further at the host-level but that's usually an exercise in futility.
I can see that we don't fundamentally disagree on many issues. Attempting to protect from all on-host attacks is pointless. Though I don't disagree with you in the majority of what we've discussed, I will always stand up for simple changes to settings that make it just that much harder for unauthorised users to cause trouble. That said those changes must not add too many onerous access requirements for authorised users. Of which, I don't believe asking people to have sudo access to your machine to have super-user access to your database is one.
Alternately, you can use sameuser privs at the local socket level, which will allow unix user foo access to Postgres user foo without a password, but only on the domain socket. That's probably the best combination of ease of use and moderate security for a dev system.
