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(at)iki(dot)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

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