Re: [HACKERS] Should creating a new base type require superuser status?
On Thu, 2008-07-31 at 09:39 +0100, Andrew Sullivan wrote: On Wed, Jul 30, 2008 at 06:07:53PM -0400, Alvaro Herrera wrote: I do agree that creating base types should require a superuser though. It too seems dangerous just on principle, even if today there's no actual hole (that we already know of). I agree. +1 -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should creating a new base type require superuser status?
On Wed, Jul 30, 2008 at 06:07:53PM -0400, Alvaro Herrera wrote: I do agree that creating base types should require a superuser though. It too seems dangerous just on principle, even if today there's no actual hole (that we already know of). I agree. -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should creating a new base type require superuser status?
On Wed, 30 Jul 2008, Alvaro Herrera wrote: I think being able to return cstring from a user defined function is quite dangerous already. I doubt we would ever give that capability to non-superusers. I do agree that creating base types should require a superuser though. It too seems dangerous just on principle, even if today there's no actual hole (that we already know of). pl/java already allows non-superusers to create functions returning cstring and base types built off of these functions. It seems safe to me if pl/java is doing the construction of cstring from a user provided java.lang.String. http://wiki.tada.se/display/pljava/Creating+a+Scalar+UDT+in+Java Kris Jurka -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should creating a new base type require superuser status?
Kris Jurka [EMAIL PROTECTED] writes: On Wed, 30 Jul 2008, Alvaro Herrera wrote: I do agree that creating base types should require a superuser though. It too seems dangerous just on principle, even if today there's no actual hole (that we already know of). pl/java already allows non-superusers to create functions returning cstring and base types built off of these functions. So in other words, if pl/java is installed we have a security hole a mile wide. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Should creating a new base type require superuser status?
Currently, you're allowed to create a new base type if you own the I/O functions for it. That effectively restricts the command to superusers anyway, since there's presently no way for a non-superuser to create a function that would have the required signature. However that's a fairly indirect protection against letting a dangerous command be executed by malicious users; and it would fail given such apparently innocent-looking changes as allowing PL functions to take or return cstring. I wonder whether we shouldn't just restrict the command to superusers explicitly, and thus affirmatively prevent possible future security holes. If you're not clear on why CREATE TYPE in the hands of a bad guy is dangerous, here are a couple of reasons: * By specifying type representation details (len/byval/align) that are different from what the type's functions expect, you could trivially crash the backend, and less trivially use a pass-by-reference I/O function to read out the contents of backend memory. * The just-added ability to specify a new type's type category and preferred status could allow subverting the behavior of existing queries that expect ambiguous operators to be resolved in a particular way. A new preferred type could capture such queries and thereby provide a trojan-horse vector for executing functions as some other user. There might be some other attacks I've not thought of. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should creating a new base type require superuser status?
Tom Lane [EMAIL PROTECTED] writes: If you're not clear on why CREATE TYPE in the hands of a bad guy is dangerous, here are a couple of reasons: * By specifying type representation details (len/byval/align) that are different from what the type's functions expect, you could trivially crash the backend, and less trivially use a pass-by-reference I/O function to read out the contents of backend memory. I know when I was first starting out it was a big source of frustration that you have to get those arguments right.. Until I figured out what they all meant and how to use them I was constantly crashing the server. It seems to me we should be able to do better. To have some kind of struct in the C code associated with the input/output functions from which the create type command picks up these parameters. As a consequence we could perhaps aim to make creating new types safe rather than just deal with the fact that it's not safe currently? It would be nice if non-superusers could create types which used an existing set of input/output functions but defined new semantics. * The just-added ability to specify a new type's type category and preferred status could allow subverting the behavior of existing queries that expect ambiguous operators to be resolved in a particular way. A new preferred type could capture such queries and thereby provide a trojan-horse vector for executing functions as some other user. Would it be enough to only require super-user to create a preferred type? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should creating a new base type require superuser status?
Gregory Stark [EMAIL PROTECTED] writes: I know when I was first starting out it was a big source of frustration that you have to get those arguments right.. Until I figured out what they all meant and how to use them I was constantly crashing the server. It seems to me we should be able to do better. To have some kind of struct in the C code associated with the input/output functions from which the create type command picks up these parameters. And what are the odds that you'll get it right in a C struct if you couldn't get it right in the SQL command? There might be some small advantage here from a packaging standpoint, but I think the argument that it'd help novice PG hackers is bogus. As a consequence we could perhaps aim to make creating new types safe rather than just deal with the fact that it's not safe currently? It would be nice if non-superusers could create types which used an existing set of input/output functions but defined new semantics. Unless you're going to allow them to create new C functions, I'm not clear on how much they're going to be able to change the semantics. * The just-added ability to specify a new type's type category and preferred status could allow subverting the behavior of existing queries that expect ambiguous operators to be resolved in a particular way. A new preferred type could capture such queries and thereby provide a trojan-horse vector for executing functions as some other user. Would it be enough to only require super-user to create a preferred type? Well, it'd close one hole, but I think there are too many others to take a narrow-gauge approach. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should creating a new base type require superuser status?
Tom Lane [EMAIL PROTECTED] writes: As a consequence we could perhaps aim to make creating new types safe rather than just deal with the fact that it's not safe currently? It would be nice if non-superusers could create types which used an existing set of input/output functions but defined new semantics. Unless you're going to allow them to create new C functions, I'm not clear on how much they're going to be able to change the semantics. Well there's plenty that can be done just using text or bytea as representations. citext, or uuid for example. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should creating a new base type require superuser status?
Tom Lane wrote: If you're not clear on why CREATE TYPE in the hands of a bad guy is dangerous, here are a couple of reasons: * By specifying type representation details (len/byval/align) that are different from what the type's functions expect, you could trivially crash the backend, and less trivially use a pass-by-reference I/O function to read out the contents of backend memory. I think being able to return cstring from a user defined function is quite dangerous already. I doubt we would ever give that capability to non-superusers. I do agree that creating base types should require a superuser though. It too seems dangerous just on principle, even if today there's no actual hole (that we already know of). -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Should creating a new base type require superuser status?
Gregory Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: Unless you're going to allow them to create new C functions, I'm not clear on how much they're going to be able to change the semantics. Well there's plenty that can be done just using text or bytea as representations. citext, or uuid for example. For the sort of look-ma-no-C programming that you seem to be envisioning, I don't think that real base types are appropriate at all. What might make sense is to handle it as a domain over some suitably-generic base type. The thing we'd have to fix to make that work is the way that the ambiguous-function resolution rules discriminate against functions that're declared to take domains. Which is hard, but it seems a lot less likely to lead to weird security risks than letting untrusted users mess with the details of base-type operations. Elein was going to go off in a corner and think about how to make that work better, but I dunno if she's gotten anywhere yet. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
