[JBoss JIRA] (WFLY-6214) Change CMTTxInterceptor.endTransaction() handling of status'
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6214?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-6214:
--------------------------------
Summary: Change CMTTxInterceptor.endTransaction() handling of status' (was: Change CMTTxInterceptor.endTransaction() handling of committing/committed/preparing/prepared to tm.commit instead of tm.suspend )
> Change CMTTxInterceptor.endTransaction() handling of status'
> ------------------------------------------------------------
>
> Key: WFLY-6214
> URL: https://issues.jboss.org/browse/WFLY-6214
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Reporter: Scott Marlow
> Priority: Blocker
> Fix For: 10.1.0.Final
>
>
> See recent comment [https://developer.jboss.org/message/950898#950898]
> {quote}
> Status.STATUS_COMMITTING:
> Status.STATUS_COMMITTED:
> Status.STATUS_PREPARED:
> Status.STATUS_PREPARING:
> * Someone has called commit in parallel and the transaction is trying to commit so try to commit too: call tm.commit
> {quote}
> I think that TimerCMTTxInterceptor/LifecycleCMTTxInterceptor are using CMTTxInterceptor.endTransaction(), so they shouldn't need changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-379) New package name for realm implementations
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-379?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-379:
------------------------------------
Assignee: Darran Lofthouse
> New package name for realm implementations
> ------------------------------------------
>
> Key: ELY-379
> URL: https://issues.jboss.org/browse/ELY-379
> Project: WildFly Elytron
> Issue Type: Task
> Components: Realms
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.1.0.Beta5
>
>
> Set to blocker as we should get this in the next Beta so we can fix the subsystem.
> Currently in the package 'org.wildfly.security.auth.provider' but they are not related to providers - security realms are not even loaded using a provider !!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2021) Prevent messages from non-members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2021?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2021:
---------------------------
Description:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
h3. Scenarios
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
was:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
h3. Scenarios
h4. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*
h4. Installing a rogue view
> Prevent messages from non-members
> ---------------------------------
>
> Key: JGRP-2021
> URL: https://issues.jboss.org/browse/JGRP-2021
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
> For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
> * Send messages to the cluster
> * Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
> * Install a new view including itself
> * Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
> h3. Goals
> 1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
> 2. Prevent a non-member from receiving any cluster messages
> The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
> h3. Proposed solution
> * Use ENCRYPT for encryption of the payload *and the headers*
> * Now _every message_ carries an encrypt header
> * (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
> * When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
> ** If the message doesn't have an encrypt header, it will be dropped
> h3. Scenarios
> h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
> * A rogue member R could catch a message from P by simply joining the same multicast group and port
> * R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
> * However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
> *R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
> h5. Installing a rogue view
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2021) Prevent messages from non-members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2021?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2021:
---------------------------
Description:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
h3. Scenarios
h4. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*
h4. Installing a rogue view
was:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
h3. Scenarios
h4. Installing a rogue view
h4. Catching a message from some member P, modifying it and re-sending it on behalf of P
* thus
> Prevent messages from non-members
> ---------------------------------
>
> Key: JGRP-2021
> URL: https://issues.jboss.org/browse/JGRP-2021
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
> For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
> * Send messages to the cluster
> * Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
> * Install a new view including itself
> * Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
> h3. Goals
> 1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
> 2. Prevent a non-member from receiving any cluster messages
> The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
> h3. Proposed solution
> * Use ENCRYPT for encryption of the payload *and the headers*
> * Now _every message_ carries an encrypt header
> * (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
> * When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
> ** If the message doesn't have an encrypt header, it will be dropped
> h3. Scenarios
> h4. Catching a message from some member P, modifying it and re-sending it on behalf of P
> * A rogue member R could catch a message from P by simply joining the same multicast group and port
> * R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
> * However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
> *
> h4. Installing a rogue view
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2021) Prevent messages from non-members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2021?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2021:
---------------------------
Description:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
h3. Scenarios
h4. Installing a rogue view
h4. Catching a message from some member P, modifying it and re-sending it on behalf of P
* thus
was:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
The goals are therefore:
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an enrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* Sent messages encrypt not just the payload but also the headers
h3. Scenarios
h4. Installing a rogue view
h4. Catching a message from some member P, modifying it and re-sending it on behalf of P
* thus
> Prevent messages from non-members
> ---------------------------------
>
> Key: JGRP-2021
> URL: https://issues.jboss.org/browse/JGRP-2021
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
> For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
> * Send messages to the cluster
> * Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
> * Install a new view including itself
> * Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
> h3. Goals
> 1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
> 2. Prevent a non-member from receiving any cluster messages
> The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
> h3. Proposed solution
> * Use ENCRYPT for encryption of the payload *and the headers*
> * Now _every message_ carries an encrypt header
> * (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
> * When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
> ** If the message doesn't have an encrypt header, it will be dropped
> h3. Scenarios
> h4. Installing a rogue view
> h4. Catching a message from some member P, modifying it and re-sending it on behalf of P
> * thus
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months