Thread: Two-phase commit security restrictions
What kind of security restrictions do we want for prepared transactions? Who has the right to finish a transaction that was started by user A? At least the original user, I suppose, but who else? Under what account is the transaction manager typically going to run? A separate TM account perhaps? Do we need a "GRANT TRANSACTION" command to give permission to finish 2PC transcations? Another approach I've been thinking about is to allow anyone that knows the (user-supplied) global transaction identifier to finish the transaction, and hide the gids of running transactions from regular users. That way, the gid acts as a secret token that's only known by the transaction manager, much like the cancel key. - Heikki
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> What kind of security restrictions do we want for prepared transactions?
> Who has the right to finish a transaction that was started by user A? At
> least the original user, I suppose, but who else?
I would say the original user, any superuser, and nobody else. This
conforms to Postgres' usual practices (compare to the right to DROP
an object).
> Do we need a "GRANT TRANSACTION" command to give permission to finish 2PC
> transcations?
Overkill.
> Another approach I've been thinking about is to allow anyone that knows
> the (user-supplied) global transaction identifier to finish the
> transaction, and hide the gids of running transactions from regular users.
Security-by-obscurity isn't really security, and I think that hiding the
GIDs is likely to make things noticeably more painful to manage.
regards, tom lane
Heikki Linnakangas wrote: > What kind of security restrictions do we want for prepared transactions? > Who has the right to finish a transaction that was started by user A? At > least the original user, I suppose, but who else? > > Under what account is the transaction manager typically going to run? A > separate TM account perhaps? > > Do we need a "GRANT TRANSACTION" command to give permission to finish > 2PC transcations? > > Another approach I've been thinking about is to allow anyone that knows > the (user-supplied) global transaction identifier to finish the > transaction, and hide the gids of running transactions from regular > users. That way, the gid acts as a secret token that's only known by the > transaction manager, much like the cancel key. Personally I prefer the last. It should be infeasible to crack as long as the gid is long enough (e.g. sufficiently random 128bit value or more) and the channel between the TM and Postgres is secure. The problem is, we cannot guarantee that a TM will generate a good random gid, or even a long enough one. (But then a good TM should assume that RM doesn't have any protection on global transactions and thus generate a good "secret-like" gid). Does the XA standard regulate about this security issue? -- dave
On Wed, Oct 13, 2004 at 11:58:21PM +0700, David Garamond wrote: > Heikki Linnakangas wrote: > >Another approach I've been thinking about is to allow anyone that knows > >the (user-supplied) global transaction identifier to finish the > >transaction, and hide the gids of running transactions from regular > >users. That way, the gid acts as a secret token that's only known by the > >transaction manager, much like the cancel key. > > Personally I prefer the last. It should be infeasible to crack as long > as the gid is long enough (e.g. sufficiently random 128bit value or > more) and the channel between the TM and Postgres is secure. So it is possible for a user connected to the DB to send random commit or cancel commands, just in case she happens to hit a valid GID? -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "La realidad se compone de muchos sueños, todos ellos diferentes, pero en cierto aspecto, parecidos..." (Yo, hablando de sueños eróticos)
Heikki Linnakangas wrote: > What kind of security restrictions do we want for prepared > transactions? Who has the right to finish a transaction that was > started by user A? At least the original user, I suppose, but who > else? Do we not require transaction initiation and conclusion to happen in the same session, so that the transaction could be considered a session-local object? -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Wed, 13 Oct 2004, Peter Eisentraut wrote: > Heikki Linnakangas wrote: >> What kind of security restrictions do we want for prepared >> transactions? Who has the right to finish a transaction that was >> started by user A? At least the original user, I suppose, but who >> else? > > Do we not require transaction initiation and conclusion to happen in the > same session, so that the transaction could be considered a > session-local object? No. After we have told the transaction manager that the transaction has been successfully prepared, we must not lose it. Otherwise we break the atomicity of the global transaction. Successful preparation is a promise to the TM that we will be able to finish the 2nd phase commit later, no matter what. - Heikki
Heikki Linnakangas wrote: > Another approach I've been thinking about is to allow anyone that knows > the (user-supplied) global transaction identifier to finish the > transaction, and hide the gids of running transactions from regular > users. That way, the gid acts as a secret token that's only known by the > transaction manager, much like the cancel key. Doesn't this break recovery? The TM needs to find all outstanding GIDs for a particular resource. I guess if we treated (database + authenticated user) as the equivalence key for XAResources (XAResource.isSameRM() in Java-speak) it might work. Then only transactions initiated by the current user need to be visible. Either way, it seems necessary to have some way for recovery to get the set of GIDs that are in doubt and the current user has permission to resolve. Otherwise the TM is going to get confused when it tries to resolve a transaction that appears to be needing recovery but it does not have permission to resolve. -O
Heikki, > Another approach I've been thinking about is to allow anyone that knows > the (user-supplied) global transaction identifier to finish the > transaction, and hide the gids of running transactions from regular users. > That way, the gid acts as a secret token that's only known by the > transaction manager, much like the cancel key. I agree with Tom; this is just inviting trouble. Restrict it to the original user and the superuser. Since any 3rd-party transaction manager (such as CJDBC) would use a single user to manage the transactions, I don't see that this restriction is a problem. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Oliver Jowett wrote: > Heikki Linnakangas wrote: > >> Another approach I've been thinking about is to allow anyone that >> knows the (user-supplied) global transaction identifier to finish the >> transaction, and hide the gids of running transactions from regular >> users. That way, the gid acts as a secret token that's only known by >> the transaction manager, much like the cancel key. > > Doesn't this break recovery? The TM needs to find all outstanding GIDs > for a particular resource. Isn't it the TM's job to remember all the outstanding GIDs? But it would be nice to ask each RM too, I guess. -- dave
David Garamond wrote: > Oliver Jowett wrote: > >> Heikki Linnakangas wrote: >> >>> Another approach I've been thinking about is to allow anyone that >>> knows the (user-supplied) global transaction identifier to finish the >>> transaction, and hide the gids of running transactions from regular >>> users. That way, the gid acts as a secret token that's only known by >>> the transaction manager, much like the cancel key. >> >> >> Doesn't this break recovery? The TM needs to find all outstanding GIDs >> for a particular resource. > > > Isn't it the TM's job to remember all the outstanding GIDs? At a minimum it has to know how to contact all resources that might be involved in in-doubt transactions. Whether it also knows all the GIDs seems to depend somewhat on the TM's transaction log implementation (e.g. it may not be logging start-of-prepare). My concern was more along the lines of how to implement Java's XAResource interface, which has 'Xid[] XAResource.recover(int flags)' i.e. the TM does not request recovery for specific transactions, it requests recovery for a whole resource. I think this is just a mapping of how the underlying XA system works, so presumably it'll be a problem for other XA-based APIs too. -O
Alvaro Herrera wrote: >>>Another approach I've been thinking about is to allow anyone that knows >>>the (user-supplied) global transaction identifier to finish the >>>transaction, and hide the gids of running transactions from regular >>>users. That way, the gid acts as a secret token that's only known by the >>>transaction manager, much like the cancel key. >> >>Personally I prefer the last. It should be infeasible to crack as long >>as the gid is long enough (e.g. sufficiently random 128bit value or >>more) and the channel between the TM and Postgres is secure. > > So it is possible for a user connected to the DB to send random commit > or cancel commands, just in case she happens to hit a valid GID? It is not essentially different from someone trying to bruteforce a password. A 128bit value like a random GUID is as strong as a 16 char password comprising ASCII 0-255 characters. And I would argue that this is _not_ security through obscurity. Security through obscurity is relying on unpublished methods/algorithms. This is not. But I understand that everybody seems to be against this idea. -- dave
David Garamond wrote: >> So it is possible for a user connected to the DB to send random commit >> or cancel commands, just in case she happens to hit a valid GID? > > > It is not essentially different from someone trying to bruteforce a > password. A 128bit value like a random GUID is as strong as a 16 char > password comprising ASCII 0-255 characters. And I would argue that this > is _not_ security through obscurity. Security through obscurity is > relying on unpublished methods/algorithms. This is not. You have no guarantees that GIDs generated by an external transaction manager are random. An obvious implementation is TM-identity plus sequence number, which is very predictable. -O