Re: function body actors (was: [PERFORM] viewing source code)
I have similar patch and it works. There is two isues: * we missing column in pg_proc about state (not all procedures are obfuscated), I solved it for plpgsl with using probin. * decrypt is expensive on language handler level. Every session have to do it again and again, better decrypt in system cache or somewhere there. Regards Pavel Stehule ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: function body actors (was: [PERFORM] viewing source code)
On Dec 21, 2007 3:18 AM, Pavel Stehule [EMAIL PROTECTED] wrote: I have similar patch and it works. There is two isues: * we missing column in pg_proc about state (not all procedures are obfuscated), I solved it for plpgsl with using probin. I was hoping to avoid making any catalog or other changes to support encryption specifically. Maybe your patch stands on its own merits...I missed the original discussion. Do you think the code you wrote can be adapted to do other things besides encryption? * decrypt is expensive on language handler level. Every session have to do it again and again, better decrypt in system cache or somewhere there. Doesn't bother me in the least...and caching unencrypted data is scary. Also, aes256 is pretty fast for what it gives you and function bodies are normally short. The real issue as I see it is where to keep the key. How did you handle that? merlin ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PERFORM] viewing source code
Bruce Momjian wrote: Is this a TODO? --- Tom Lane wrote: Merlin Moncure [EMAIL PROTECTED] writes: I don't really agree that wrapping pl/pgsql with encryptor/decryptor is a bad idea. It's quite a good idea, because it has more than zero chance of succeeding politically in the community. The fundamental reason why preventing access to pg_proc.prosrc won't happen is this: all the pain (and there will be plenty) will be inflicted on people who get none of the benefit (because they don't give a damn about hiding their own functions' code). The folks who want function hiding can shout all they want, but as long as there is a very sizable fraction of the community who flat out *don't* want it, it's not going to get applied. Encrypted function bodies avoid this problem because they inflict no performance penalty, operational complexity, or client-code breakage on people who don't use the feature. They are arguably also a better solution because they can guard against more sorts of threats than a column-hiding solution can. I don't deny that the key-management problem is interesting, but it seems soluble; moreover, the difficulties that people have pointed to are nothing but an attempt to move the goalposts, because they correspond to requirements that a column-hiding solution would never meet at all. So if you want something other than endless arguments to happen, come up with a nice key-management design for encrypted function bodies. I keep thinking the problem of keys is similar that of Apache servers which use certificates that require passphrases. When the server is started, the passphrase is entered on the command line. -- Dan Langille - http://www.langille.org/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PERFORM] viewing source code
On Dec 21, 2007 9:34 AM, Bruce Momjian [EMAIL PROTECTED] wrote: Is this a TODO? I don't think so, at least not yet (it's not clear what if anything there is to do). see: http://archives.postgresql.org/pgsql-hackers/2007-12/msg00788.php merlin ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: function body actors (was: [PERFORM] viewing source code)
On 21/12/2007, Merlin Moncure [EMAIL PROTECTED] wrote: On Dec 21, 2007 3:18 AM, Pavel Stehule [EMAIL PROTECTED] wrote: I have similar patch and it works. There is two isues: * we missing column in pg_proc about state (not all procedures are obfuscated), I solved it for plpgsl with using probin. I was hoping to avoid making any catalog or other changes to support encryption specifically. Maybe your patch stands on its own merits...I missed the original discussion. Do you think the code you wrote can be adapted to do other things besides encryption? I don't know. It was fast hack that just works. It hat to do obfuscation, and it do it well. * decrypt is expensive on language handler level. Every session have to do it again and again, better decrypt in system cache or somewhere there. Doesn't bother me in the least...and caching unencrypted data is scary. Also, aes256 is pretty fast for what it gives you and function bodies are normally short. The real issue as I see it is where to keep the key. How did you handle that? merlin Simply. I use for password some random plpgsql message text and compile it. I though about GUC, and about storing password in postgresql.conf. It's equal to protection level. We cannot protect code on 100%. If you have admin or superuser account and if you know some internal, you can simply get code. http://blog.pgsql.cz/index.php?/archives/10-Obfuscator-PLpgSQL-procedur.html#extended sorry for czech desc Pavel ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PERFORM] viewing source code
Is this a TODO? --- Tom Lane wrote: Merlin Moncure [EMAIL PROTECTED] writes: I don't really agree that wrapping pl/pgsql with encryptor/decryptor is a bad idea. It's quite a good idea, because it has more than zero chance of succeeding politically in the community. The fundamental reason why preventing access to pg_proc.prosrc won't happen is this: all the pain (and there will be plenty) will be inflicted on people who get none of the benefit (because they don't give a damn about hiding their own functions' code). The folks who want function hiding can shout all they want, but as long as there is a very sizable fraction of the community who flat out *don't* want it, it's not going to get applied. Encrypted function bodies avoid this problem because they inflict no performance penalty, operational complexity, or client-code breakage on people who don't use the feature. They are arguably also a better solution because they can guard against more sorts of threats than a column-hiding solution can. I don't deny that the key-management problem is interesting, but it seems soluble; moreover, the difficulties that people have pointed to are nothing but an attempt to move the goalposts, because they correspond to requirements that a column-hiding solution would never meet at all. So if you want something other than endless arguments to happen, come up with a nice key-management design for encrypted function bodies. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] function body actors (was: [PERFORM] viewing source code)
On Fri, Dec 21, 2007 at 12:09:28AM -0500, Merlin Moncure wrote: Maybe a key management solution isn't required. If, instead of strictly wrapping a language with an encryption layer, we provide hooks (actors) that have the ability to operate on the function body when it arrives and leaves pg_proc, we may sidestep the key problem (leaving it to the user) and open up the doors to new functionality at the same time. I like this idea much better, because the same basic mechanism can be used for more than one thing, and it doesn't build in a system that is fundamentally weak. Of course, you _can_ build a weak system this way, but there's an important difference between building a fundamentally weak system and making weak systems possible. A ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: function body actors (was: [PERFORM] viewing source code)
On Fri, Dec 21, 2007 at 12:40:05AM -0500, Tom Lane wrote: whether there is a useful policy for it to implement. Andrew Sullivan argued upthread that we cannot get anywhere with both keys and encrypted function bodies stored in the same database (I hope that's an adequate summary of his point). It is. I'm not a security expert, but I've been spending some time listening to some of them lately. The fundamental problem with a system that stores the keys online in the same repository is not just its potential for compromise, but its brittle failure mode: once the key is recovered, you're hosed. And there's no outside check of key validity, which means attackers have a nicely-contained target to hit. I'm not convinced that he's right, but that has to be the first issue we think about. The whole thing is a dead end if there's no way to do meaningful encryption --- punting an insoluble problem to the user doesn't make it better. Well, one thing you could do with the proposal is build a PKCS#11 actor, that could talk to an HSM. Not everyone needs HSMs, of course, but they do make online key storage much less risky (because correctly designed ones make key recovery practically impossible). So the mechanism can be made effectively secure even for very strong cryptographic uses. Weaker cases might use a two-level key approach, with a data-signing key online all the time to do the basic encryption and validation, but a key-signing key that is always offline or otherwise unavailable from within the system. The key signing key only authenticates (and doesn't encrypt) the data signing key. You could use a different actor for this, to provide an interface to one-way functions or something. This gives you a way to revoke a data-signing key. You couldn't protect already compromised data this way, but at least you could prevent new disclosures. Yes, I'm being hand-wavy now, but I can at least see how these different approaches are possible under the suggestion, so it seems like a possibly fruitful avenue to explore. The more I think about it, actually, the more I like it. A ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] viewing source code
It seems like a lot of people only saw hide source code in the original message, and then went off on tangents that don't have anything to do with the request. Again: On 12/14/07, Roberts, Jon [EMAIL PROTECTED] wrote: Is it possible yet in PostgreSQL to hide the source code of functions from users based on role membership? I would like to avoid converting the code to C to secure the source code and I don't want it obfuscated either. In an ideal world, if a user can't modify a function, he/she shouldn't be able to see the source code. If the user can execute the function, then the user should be able to see the signature of the function but not the body. As a Role under PostgreSQL, I can create tables, views, functions, etc. As the owner of those objects, I can control what other roles can view data through them, and what roles can modify them. However, unlike tables, I cannot control what roles can view the data contained within my PL functions (body). That's it. A very simple problem. One that has absolutely nothing whatsoever to do with encrypted storage on disk or hiding things from DBAs or superusers. I'm surprised this group ended up so far off point. It's not as if objecting to this requires a bunch of abstract hyperbole, just a simple it's not worth the effort and it's considered a bad idea to put security-senstive data inside PL function bodies. On 12/20/07, Joshua D. Drake [EMAIL PROTECTED] wrote: On Thu, 20 Dec 2007 10:47:53 -0800 Trevor Talbot [EMAIL PROTECTED] wrote: This feature as it is called can be developed externally and has zero reason to exist within PostgreSQL. If the feature has the level of demand that people think that it does, then the external project will be very successful and that's cool. I'm unsure of what you consider external here. Is SE-PostgreSQL the type of thing you mean? I don't know that it needs to be that extensive. I noted elsewhere in the thread the idea of a plpgsql_s. I think that is an interesting idea. I just don't think it needs to be incorporated into postgresql-core. I was trying to get a handle on whether you meant external as in middleware, or external as in third-party patches to PostgreSQL. The OP's request doesn't necessarily need something as extensive as SE-PostgreSQL, but it needs to be on the same level: something that affects the database surface clients see, not apps behind middleware. On 12/20/07, Tom Lane [EMAIL PROTECTED] wrote: Merlin Moncure [EMAIL PROTECTED] writes: I don't really agree that wrapping pl/pgsql with encryptor/decryptor is a bad idea. It's quite a good idea, because it has more than zero chance of succeeding politically in the community. Something that looks a lot like encryption of the entire database is more likely to succeed politically than a simple addition to PostgreSQL's existing role-based security model? Really? It's not like I can claim otherwise, I'm just wondering if I woke up in an alternate universe this morning... The fundamental reason why preventing access to pg_proc.prosrc won't happen is this: all the pain (and there will be plenty) will be inflicted on people who get none of the benefit (because they don't give a damn about hiding their own functions' code). The folks who want function hiding can shout all they want, but as long as there is a very sizable fraction of the community who flat out *don't* want it, it's not going to get applied. I don't understand. Can you give an example of pain you see coming? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PERFORM] viewing source code
I wrote: That's it. A very simple problem. It was hinted to me off-list that my mail was fanning the flames, so to clarify: when I say things like the above, I mean conceptually. I think there might be a shared pool of knowledge that says it's anything but simple in practical terms, but that hasn't been communicated clearly in this thread. That's what I was getting at. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PERFORM] viewing source code
Trevor Talbot [EMAIL PROTECTED] writes: Something that looks a lot like encryption of the entire database is more likely to succeed politically than a simple addition to PostgreSQL's existing role-based security model? Really? I guess that you have failed to understand any of the discussion. Adding a GRANT SEESOURCECODE ON FUNCTION type of privilege would perhaps be a simple addition to PostgreSQL's existing security model, but it would accomplish precisely zero, because anyone smart enough to be using Postgres in the first place would simply look directly into pg_proc to see the function body. In order to make it into a meaningful restriction, we would have to restrict direct SQL access to the system catalogs --- at least that one --- which would break vast quantities of stuff. The fact that psql, pg_dump, and pgAdmin would all break is daunting in itself, but those are likely just the tip of the iceberg. Looking at the system catalogs has always been part of the culture around here, and it's impossible to guess how many one-off client programs do it. I'd bet on a lot, though. Another problem is that you're facing a cultural bias. You quote On 12/14/07, Roberts, Jon [EMAIL PROTECTED] wrote: In an ideal world, if a user can't modify a function, he/she shouldn't be able to see the source code. but what neither of you apparently grasp is that to most open source programmers, that's not an ideal world, that's a pretty good description of hell on earth. There is no way that you will persuade this project that hiding source code should be the default behavior, or even especially easy. We're willing to think about ways to hide source code where there is a really serious commercial imperative to do it --- but in cases like that, schemes that are as easily broken into as a SQL-level GRANT are probably not good enough anyhow. And thus we arrive at encrypted source text and discussions of where to keep the key. Once again: this discussion is 100% off-topic for pgsql-performance. If you want to keep talking about it, please join the child thread on pgsql-hackers. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PERFORM] viewing source code
On Thu, Dec 20, 2007 at 02:02:57PM -0600, Roberts, Jon wrote: I'm tired of arguing. You win. I still say this I a needed feature if you want adoption for enterprise level databases in larger companies. The security out of the box is not enough What a classic I want this, and if it isn't implemented postgres sucks argument. Mike Stone ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
