Application name patch - v2
in [PgSql]
|
Prev: Hot standby status
Next: per table random-page-cost?
From: Pavel Stehule on 19 Oct 2009 05:22 2009/10/19 Dave Page <dpage(a)pgadmin.org>: > On Mon, Oct 19, 2009 at 10:01 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: > >> There are some log parser's and analysers. So people use reduced log >> often. The reductions rules should be based on application name. Why >> not? And when somebody modifies to appliacation name, then these logs >> finish in '/dev/null. > > So if your insecure app worries you, just don't use %a in the log > prefix, or ignore the column in the CSV logs. I'll know so %a is insecure, but what other users? Every live application is potencially insecure. I agree, so this value is useful for debuging, but with proposed features the value is diskutable. Pavel > > > > -- > Dave Page > EnterpriseDB UK: Â http://www.enterprisedb.com > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 19 Oct 2009 05:24 2009/10/19 Andrew Dunstan <andrew(a)dunslane.net>: > > > Pavel Stehule wrote: >> >> 2009/10/19 Andrew Dunstan <andrew(a)dunslane.net>: >> >>> >>> Pavel Stehule wrote: >>> >>>> >>>> 2009/10/19 Dave Page <dpage(a)pgadmin.org>: >>>> >>>> >>>>> >>>>> On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule >>>>> <pavel.stehule(a)gmail.com> >>>>> wrote: >>>>> >>>>> >>>>>> >>>>>> I dislike write access to app name guc for user too. It's not safe. >>>>>> Maybe only super user can do it? >>>>>> >>>>>> >>>>> >>>>> That'll render it pretty useless, as most applications wouldn't then >>>>> be able to set/reset it when it makes sense to do so. >>>>> >>>>> >>>> >>>> But application can do it simply via connection string, no? Mostly >>>> applications has connection string in configuration, so I don't see >>>> problem there. And if I would to allow access, then I could to wrap >>>> setting to security definer function. >>>> >>>> I see this as security hole. It allows special SQL injection. >>>> >>>> >>>> >>> >>> How is it any more a security hole than any other setting that the user >>> can >>> alter with an arbitrary string value (e.g. custom options)? >>> >>> >> >> Others GUC has not important role in logs. It's similar as possibility >> to change client IP address. >> >> > > That doesn't even remotely answer the question. How is such a thing a vector > for an SQL injection attack, that does not apply to other GUCs? If your > answer is that log parsers will try to inject the values, then it those > programs that need to be fixed, rather than restricting this facility in a > way that will make it close to pointless. > good designed parsers will not have a problem. But lot of parser is based in custom rules. And these rules should be not 100% safe. This proposal increase risks. Pavel > And no, it is not at all the same as changing the client's IP address. > > cheers > > andrew > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dave Page on 19 Oct 2009 05:31 On Mon, Oct 19, 2009 at 10:22 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: > 2009/10/19 Dave Page <dpage(a)pgadmin.org>: >> On Mon, Oct 19, 2009 at 10:01 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >> >>> There are some log parser's and analysers. So people use reduced log >>> often. The reductions rules should be based on application name. Why >>> not? And when somebody modifies to appliacation name, then these logs >>> finish in '/dev/null. >> >> So if your insecure app worries you, just don't use %a in the log >> prefix, or ignore the column in the CSV logs. > > I'll know so %a is insecure, but what other users? Every live > application is potencially insecure. I agree, so this value is useful > for debuging, but with proposed features the value is diskutable. %a is not 'insecure'. It's user-configurable. There's a difference. If you don't trust your application or your users not to change the application name, then don't rely on it in your logs or stats. For other users that do trust their app and don't expect their users to be going out of their way to mislead the DBA, this can be a useful feature, as it's proven to be for others that have used the equivalent facilities in other DBMSs. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 19 Oct 2009 05:41 2009/10/19 Dave Page <dpage(a)pgadmin.org>: > On Mon, Oct 19, 2009 at 10:22 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >> 2009/10/19 Dave Page <dpage(a)pgadmin.org>: >>> On Mon, Oct 19, 2009 at 10:01 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >>> >>>> There are some log parser's and analysers. So people use reduced log >>>> often. The reductions rules should be based on application name. Why >>>> not? And when somebody modifies to appliacation name, then these logs >>>> finish in '/dev/null. >>> >>> So if your insecure app worries you, just don't use %a in the log >>> prefix, or ignore the column in the CSV logs. >> >> I'll know so %a is insecure, but what other users? Every live >> application is potencially insecure. I agree, so this value is useful >> for debuging, but with proposed features the value is diskutable. > > %a is not 'insecure'. It's user-configurable. There's a difference. > > If you don't trust your application or your users not to change the > application name, then don't rely on it in your logs or stats. For > other users that do trust their app and don't expect their users to be > going out of their way to mislead the DBA, this can be a useful > feature, as it's proven to be for others that have used the equivalent > facilities in other DBMSs. I thing, so it should be more useful for DBA - mostly databases are used in web sphere, if write access should be configurable. I understand, so in local application nobody have to be paranoic and restricted access looks unuseful, but on web sphere you have to be paranoic and there the application name should be immutable in session. I like to use this value too, really. But I am working mostly with web applications, and I see risks. Pavel > > -- > Dave Page > EnterpriseDB UK: Â http://www.enterprisedb.com > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dave Page on 19 Oct 2009 06:12
On Mon, Oct 19, 2009 at 10:45 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: > sure, you have to fix fulnerable application. But with some > unsophisticated using %a and using wrong tools, the people can be > blind and don't register an SQL injection attack. If they're logging the statements (which they presumably are if looking for unusual activity), then they'll see the attack: dpage(a)myapp: LOG: connection authorized: user=dpage database=postgres dpage(a)myapp: LOG: statement: set application_name='hax0red'; dpage(a)hax0red: LOG: disconnection: session time: 0:00:20.152 user=dpage database=postgres host=[local] -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |