Re: [HACKERS] Disabling trust/ident authentication configure option
On Wed, May 20, 2015 at 5:21 PM, Robert Haas robertmh...@gmail.com wrote: Please don't be discouraged here. Contributing to the PostgreSQL community can be frustrating when you don't get what you want, and even though I have been a member of this community for about 7 years now and am a major contributor and committer, I still very often do not get what I want. But please don't view that as a personal rejection. I stand by what I said: disallowing trust authentication in pg_hba.conf will not slow down an attacker who wants to create a backdoor. I believe that to be true, and I can tell you why, but regardless of anything I say, you can still believe it to be false. I'm OK with that, and I hope you're OK with me having a different belief. It doesn't mean that I don't want you to continue reading this mailing list or suggesting things; in fact, I hope you will. The fact that I (and others) don't like this particular idea doesn't mean we won't like your next one, or the one after that. If this discussing has come across as bruising, I apologize for that. One of the things that sometimes happens is that somebody submits a patch and it goes for a long time without receiving any meaningful feedback. Then eventually, sometimes after a lot of work has been put into it, it gets rejected. That's not fun. So another approach is for people to respond right away when somebody posts a patch that they think is a bad idea and say: hey, wait, let's not do this, I think it's a bad idea. But then you can have a situation (which I think may have happened in this case) where a contributor feels that other people are jumping all over them. That's not fun, either. I don't know the answer to this problem. I'm not the world's greatest diplomat, and tone is even harder to read over email than it is in person. But I can tell you that I'm not mad at you personally, and I didn't spend time replying to this email thread just to get rid of you. If it came across that way, I'm sorry. Yes I guess discussing via mail always lends itself to misinterpretations, and people tend to read the worst possible interpretation :) So I am not offended and also did not intend to offend you in my reply. I likely just viewed this too much through a security lens - you see a possible attack scenario, a way to turn it off, and only minor downsides, so just go for it - but this is not how you can work in a huge open source project. I guess as a developer you would have to take many other issues (like maintainability, user confusion because of the change, edge use cases) into account. And as it seems to cause too much trouble for official inclusion I am fine with patching it during our package build. And yes once someone has write access to your pg_hba.conf you are very likely doomed. This would just prevent an attack happening through a careless trust entry left there, which is just a very quick win for an attacker, and may be a bit less likely through this patch. To answer to Tom: I see a restricted audience for this patch, but also no impact for anyone not wanting to use it. The group of users I see would be as follows: * People who package PostgreSQL as part of their product and want to provide their customers with a restricted more secure functionality set only to reduce training and support effort. (my use case) * People with large Postgres deployments who build their own packages and want to enforce a certain security policy (e.g. services are not allowed to offer authentication-less access over the network) - specifically a good security plan would be to only allow a safe subset of methods and ensure that these are well documented and perhaps audited automatically - this would also allow ensuring there is only one documented / audited way to reset passwords (modulo single user mode, that is an additional problem which won't be easily fixable) * Distributions which want to provide a more secure package and want to ensure each available method can be configured securely and documented clearly for their specific setup. It does not apply to (or would have a negative effect for) the following groups: * PostgreSQL users on Windows (disabling trust should not work or should show a very prominent warning) * Users of default builds (they simply won't be affected) * People with a specific use case requiring trust, ident or for the more generic patch other specific auth methods. They will be affected if they happen to be using a build with this method turned off. * People who are used to resetting passwords using trust and are surprised this suddenly does not work on some specific system My guess is the group who actually profit is relatively small, but the group of people actively affected would also be relatively small. I have no idea about actual usage so I am not qualified to judge here :)
Re: [HACKERS] Disabling trust/ident authentication configure option
On Tue, May 19, 2015 at 1:53 AM, Robert Haas robertmh...@gmail.com wrote: On May 18, 2015, at 3:32 PM, Volker Aßmann volker.assm...@gmail.com wrote: I know these measures won't protect against an experienced attacker who gains root access, but hope it slows them down sufficiently so the admins may have a chance to detect the attack. It won't. You don't seem to have much trust in your other authentication mechanisms and seem to know our environment quite well then... But anyway you don't seem to understand why being able to remove a 'disable all security let anyone in' option might be a reasonable idea, so there is no point in arguing, please just ignore the patch.
Re: [HACKERS] Disabling trust/ident authentication configure option
On Mon, May 18, 2015 at 5:58 AM, Josh Berkus j...@agliodbs.com wrote: Let's say we offered a compile-time option, and then someone built a package postgresql-9.6-secureauth.deb. So, your lazy admin is having trouble debugging an auth problem and wants to set trust. But they can't. So they search on Google and figure out how to download and install postgresql-9.6-normalauth.deb. Or, alternately, they set all passwords to password or to . Or they put .pgpass files on all machines. Or they put the password in pgbouncer and set pgbouncer to trust. We have a specific use case were servers don't connected directly to the internet (package replacement is hard) and the client application manages credentials in a reasonably secure fashion. Of course these measures are rendered moot if some careless admin can just set authentication to trust for a quick upgrade and forgets about this. I know these measures won't protect against an experienced attacker who gains root access, but hope it slows them down sufficiently so the admins may have a chance to detect the attack. Now, if you wanted to add an audit log every time someone changes an auth method in pg_hba.conf? I'd be all for that, I can see all kinds of uses for that, and it might actually accomplish something effective. This would also be a valuable security measure to implement. If you disagree with me, well, it would be very easy to hack out the auth methods you don't like and compile your own. It *is* open source. That's what we are currently doing with the patch Bernd posted at the beginning of this thread. But we thought we might post the patch for consideration here as the use case might be sufficiently general that it may be of use to others. But I like the more general approach proposed by Alvaro, so in case this patch would have a chance to not be immediately rejected, I would try to implement the more generic approach. I would also include a check to ensure at least one reasonably secure way for password recovery is available. For Unix systems peer authentication seems to be a good candidate. Best regards, Volker
Re: [HACKERS] Disabling trust/ident authentication configure option
Yes, I'd like to know if Alvaros suggestion would in deed achieve consensus (possibly with Andrews addition). It looks like the most general solution but might be some work using autoconf ... Best regards, Volker On Wed, May 13, 2015 at 2:18 PM, Robert Haas robertmh...@gmail.com wrote: On Wed, May 13, 2015 at 8:01 AM, Volker Aßmann volker.assm...@gmail.com wrote: Even in this case it still means that any breach in any of the network services running on your application server would immediately own your database, or at least everything your application can access. This applies even to totally unrelated services running with restricted permissions. Using password or certificate based authentication at least gives you the additional security of local filesystem access controls and is not much harder to setup. M2M authentication is always a difficult topic as the authentication tokens have to be secured but I would agree that a more specific / secure method than disable-all-authentication would be preferable. Sure, opinions on the best way to do any given thing are going to vary, and nobody's trying to prevent you from configuring your instances of PostgreSQL however you like. The email to which I was responding was suggesting limiting MY ability to set up MY instances of PostgreSQL the way I like. And I'm opposed to that. All of this is fairly far afield from the original topic of this thread, which was whether a configure option disabling trust + ident authentication would be a good idea. I said no. Then we had a bunch of counter-proposals: Alvaro: Support a configure switch whose value is a comma-separated list of authentication methods to disable. Peter: Generalized hardening facility. Andrew: Like what Alvaro said, but require at least one of trust + peer to remain enabled so people can't hose themselves. Andrew, v2: Rip out RFC1413 ident authentication completely. Stephen: Require a command-line option to use trust auth. There's clearly no consensus on any of these proposals, and most of them don't address your original requirement anyway, though Alvaro's would. I guess the point is that nothing is going to get changed here on one person's say-so if other people don't agree, so if you want to get something done, you're going to need to pick something that can achieve consensus and then implement that. Also, anything you want to get done is certainly going to be in 9.6 at the earliest, because the time for 9.5 proposals has already come and gone. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: [HACKERS] Disabling trust/ident authentication configure option
On Mon, May 11, 2015 at 10:00 PM, Robert Haas robertmh...@gmail.com wrote: On Thu, May 7, 2015 at 4:57 PM, Stephen Frost sfr...@snowman.net wrote: * Robert Haas (robertmh...@gmail.com) wrote: On Thu, May 7, 2015 at 11:02 AM, Stephen Frost sfr...@snowman.net wrote: I realize it's not going to be popular, but I'd love to have 'trust' only allowed if a command-line option is passed to the postmaster or something along those lines. It's really got no business being an option for a network service like PG. I disagree wholeheartedly. There is such a thing as a trusted network. Likely a good topic of conversation to be had in Ottawa. :) I agree that there are trusted networks, but the ones that I work with still expect network services to require authentication and authorization. Perhaps they're not really trusted then, from your perspective. On the other hand, I suppose if you use pg_hba to limit which accounts can be logged into with 'trust' then you might be able to have, say, a read-only user/database that anyone could see. That's a pretty narrow case though and I'd rather we figure out how to address it directly and more specifically (no-password login roles?) than the broad disable-all-authentication trust method. Let's suppose that you have an application server and a DB server running on the same node. That turns out to be too much load, so you move the application server to a separate machine and connect the two machines with a crossover cable, or a VLAN that has nothing else on it. To me, it's quite sane to want connections on that network to proceed without authentication or authorization. If you've got to open up the database more than that then, yes, you need authentication and authorization. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company Even in this case it still means that any breach in any of the network services running on your application server would immediately own your database, or at least everything your application can access. This applies even to totally unrelated services running with restricted permissions. Using password or certificate based authentication at least gives you the additional security of local filesystem access controls and is not much harder to setup. M2M authentication is always a difficult topic as the authentication tokens have to be secured but I would agree that a more specific / secure method than disable-all-authentication would be preferable. Best regards, Volker
Re: [HACKERS] Disabling trust/ident authentication configure option
On Wed, May 6, 2015 at 4:47 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Robert Haas wrote: I frankly find that a bit difficult to swallow. You think that everyone knows that bad passwords are a problem, but some people might not realize that an authentication method called trust might not be secure? Ultimately, what we offer to users is choice of a few options. Should we only offer options that we consider to be completely secure, and no others? If we were to follow that principle, we would completely disable non-SSL builds, and all auth methods other than, I dunno, GSSAPI and such. But we don't do that, because we trust that users will use whatever is most appropriate for them. I see this patch is, in a way, a mechanism to let system administrators choose at compile time what options are available to DBAs at setup time. This seems a reasonable thing to me. Yes in fact, it would be a way for organizations distributing their own PostgreSQL packages to enforce authentication restrictions within the package instead of having to educate all users about the options. I don't necessarily agree with the patch as proposed. I would rather have a comma-separated list of methods, as in: --disable-auth=ident,peer Something more general like that would be even better, and when reading the comments below perhaps also the option to differentiate between local and remote authentication. I will look into this and see if we could update the patch to a more generic option in case people here agree that it is worthwhile. I would be adding additional options: --disable-remote-auth=ident,trust --disable-local-auth=trust And would check that there is a warning about the password reset restrictions in case both peer and trust (and on Windows?) are disabled. which lets you choose what to disable without hardcoded choices. Due to the nature of autoconf, this might be too fiddly to implement, though, and if so I think the method proposed by this patch seems a reasonable compromise. I've seen configure in other programs offer options such as --disable-foo=list that lists acceptable values (or --disable-foo=help) -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
Re: [HACKERS] Disabling trust/ident authentication configure option
On Tue, May 5, 2015 at 10:39 PM, Robert Haas robertmh...@gmail.com wrote: On Tue, May 5, 2015 at 8:05 AM, Volker Aßmann volker.assm...@gmail.com wrote: Changing the password to something simple is immediately obvious as a security flaw for most people who may come across database configurations, but for the TRUST mode you actually need to know some background on why this is dangerous and when. I frankly find that a bit difficult to swallow. You think that everyone knows that bad passwords are a problem, but some people might not realize that an authentication method called trust might not be secure? I suppose that's possible, but I really think that if you install an *authentication method* whose name means *just trust the other guy to be telling the truth* without thinking about the consequences of that, it's hard to have a lot of sympathy for whatever happens afterwards. Well trust actually does not sound that dangerous in case you only take a quick glance at the documentation - trust PostgreSQL to do the right thing? - so this at least requires to actively read about this, while any person working in IT should have at least a rough understanding that weak passwords are bad... And trust is IMHO dangerous because even people who might know about the dangers may choose to temporarily turn it on (let me just finish this update and I will worry about the authentication settings later) and then forget to disable it again - aka it might actually be useful... Besides, your patch doesn't just disable trust. It also disables ident authentication, which in some network configurations could conceivably be more secure than password authentication. When applied to the local machine, ident actually means peer, which has an *excellent* chance of being more secure than password authentication. For that matter, even trust might be better than password. Anybody who can sniff the network traffic can read the password right off of the wire. So either way, your PostgreSQL server is gonna get hacked, but if you use password authentication, you might reveal a password that is also used to protect access to something else that used to be secure. You are right, ident is not the same ättack vector as trust, you most likely won't activate this by accident, but I think it is still a dangerous mode that would be reasonable to deactivate if it's not needed. Personally, if I were going to start disabling authentication methods at compile time, I'd start with password and md5. If you are not using SSL, and you use password or md5 authentication, you're basically saying, well, I'm OK with somebody reading all of the data that I'm sending and receiving over the wire, and I'm willing to take the risk that my passwords are easily crackable or can be read straight off the wire using wireshark, but to send your own queries you will have to make at least some minimal effort. If you need real security, that is not nearly good enough. If you don't need real security, why bother making people hassle with a password that's not providing any real protection? There are some valid answers to that question - e.g. if you are on a corporate WAN, you probably can't fire somebody for blundering into an unprotected resource, but if somebody goes to the trouble of cracking the password, even if it's weak, then you can probably nail them. For most users, though, I think password and md5 authentication serve mostly to give people the illusion that they've secured the server. The real security, if there is any, comes primarily from restricting incoming connections via listen_addresses and/or operating system mechanisms such as iptables and/or pg_hba.conf, and from requiring the use of SSL. Passwords are weak sauce. Yes, passwords can be as bad as trust authentication or basically any other method done implemented insecurely, so from my point of view the best solution would be to be able to selectively enable/disable all authentication methods to customize the package for specific environments. Trust is in my point of view just the most immediately obvious shoot yourself in the foot option and in my use case the thing that users are actually bound to try and get wrong. Please note that the patch does nothing by default, it just adds the option to disable trust/ident but leaves them on in the standard configuration. I do not want to disable trust by default for everyone, but it would be great to have the option to do this without having to patch (and thus test and verify) the PostgreSQL sources for each new release. I think this is a sufficiently general requirement to warrant including an option to disable this, as most hardening guides I have seen for PostgreSQL unconditionally require to disable trust authentication and disabling it in the code removes the need to check this in the runtime configuration. A final point to consider is: what happens when you lock yourself out
Re: [HACKERS] Disabling trust/ident authentication configure option
Hello, I am the one who suggested the patch to Credativ, so let me explain my reasoning. It is clear that it is basically impossible to get perfect security but this patch would help to solve one small but for our use case quite dangerous issue. Changing the password to something simple is immediately obvious as a security flaw for most people who may come across database configurations, but for the TRUST mode you actually need to know some background on why this is dangerous and when. Especially as it is well documented it might seem legit to some people who are not that experienced with postgres setup. I think this case is sufficiently generic to be applicable to many others and to justify to at least provide the option to work around it. Preventing such configuration errors is a usual topic in most hardening guidelines and most commercial databases take steps to offer more secure mechanisms to implement passwordless access or reset passwords. Regarding passwords what you are saying is basically a People can leave their windows open anyways, so why bother installing door locks kind of argument. In my opinion the secure way to go would be to allow exactly one defined way to access the DB without authentication / reset authentication tokens and make this way easily recognizable / auditable. A nice addition would be to be able to force password policies (e.g. using passwordcheck + something like cracklib)... So please consider to include this patch as it does not change the default behavior but implement a simple way to comply with security policies and actually increase security for some specific use cases. BR, Volker Aßmann On Thu, Apr 30, 2015 at 2:00 PM, Robert Haas robertmh...@gmail.com wrote: On Thu, Apr 16, 2015 at 9:55 AM, Bernd Helmle maili...@oopsware.de wrote: PostgreSQL is deployed as part of a larger technical solution (e.g. a Telecommunication system) and a field engineer has to install/upgrade this solution. The engineer is a specialist in the Telco domain and has only little knowledge of databases and especially PostgreSQL setup. We now want to provide these kinds of users with pre-hardened packages that make it very hard to accidentally expose their database. For this purpose the patch allows to optionally disable the trust and ident authentication methods. Especially the trust mechanism is very critical as it might actually provide useful functionality for our user. Think of an engineer who has to do a night shift upgrade with a customer breathing down his neck to get the system back online. Circumventing all these authentication configuration issues by just enabling trust is very easy and looks well supported and documented. But... the user could use password authentication with the password set to x and that would be insecure, too, yet not prevented by any of this. I think it's pretty hard to prevent someone who has filesystem-level access to the database server from configuring it insecurely. Of course, it's fine for people to make changes like this in their own copies of PostgreSQL, but I'm not in favor of incorporating those changes into core. I don't think there's enough general utility to this to justify that, and more to the point, I think different people will want different things. We haven't, for example, ever had a request for this specific thing before. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
