Bug 977891 - AMQP 1.0 would allow bypassing of authorisation and connection limits
AMQP 1.0 would allow bypassing of authorisation and connection limits
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
Development
Unspecified Unspecified
high Severity unspecified
: 3.0
: ---
Assigned To: Gordon Sim
Zdenek Kraus
:
Depends On:
Blocks: 1010399
  Show dependency treegraph
 
Reported: 2013-06-25 10:23 EDT by Gordon Sim
Modified: 2015-01-21 07:57 EST (History)
5 users (show)

See Also:
Fixed In Version: qpid-qmf-0.22-7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Apache JIRA QPID-4712 None None None Never

  None (edit)
Description Gordon Sim 2013-06-25 10:23:59 EDT
Description of problem:



Version-Release number of selected component (if applicable):

qpid 0.22

How reproducible:

100%

Steps to Reproduce:
1. set an acl policy to restrict access to queues/exchanges in some way
2. try sending or receiving from those queues/exchanges using 0-10
3. try sending or receiving from those queues/exchanges using 1.0

Actual results:

1.0 connections bypass rules, 0-10 connections enforce the rules

Expected results:

both versions enforce the rules

Additional info:

The goal is to ensure that enabling AMQP 1.0 doesn't allow any existing authorisation policy to be circumvented. The existing rules are heavily influenced (distorted?) by AMQP 0-10 without directly following the that version in full. A redesign of the permissioning model to be more generic would make things more intuitive for AMQP 1.0 users, but is considered out of scope for the time being.

Link attachment (i.e. creating a sender or receiver) will always require access permission to the node in question (i.e. the queue or exchange). Generally there will be other permissions required as well.

To attach as a sender to a queue, publish permission is required for the default exchange (amq.default keyword in ACL file) with the queue name as the routing key. For a sending link to an exchange the publish permission cannot be checked on attach since the routing key is unknown at that point. This is similar to 0-10 and the publish permission will be checked (if and only if there are any publish rules) for each message (again, exactly like 0-10).

To attach as a receiver from a queue, consume permission is also required for the queue in question. To attach as a receiver from an exchange, create and consume permission will be required for the subscription queue. The name of this is chosen by the broker, but it uses the container id (which can be set as a connection option in qpid::messaging) and the link name (which can be set as the name proerty in link properties of address in qpid::messaging). In addition bind permission is required for the exchange in question. Note however that unbind permission is not required in order to detach, as that permission is implied (it will happen anyway).

In the 1.0 codepath, the properties used in checking access etc are those of the node (queue or exchange). In AMQP 0-10 by contrast the fields of the command being checked are used instead (which leads to some anomalies in my view since e.g. queue-query doesn't involve any test for autodelete, exclusive etc as would a passive declare).
Comment 1 Gordon Sim 2013-06-25 10:25:12 EDT
Fixed upstream by https://svn.apache.org/r1496466
Comment 2 Gordon Sim 2013-06-25 13:44:46 EDT
Also need further fix upstream for windows and rhel5: https://svn.apache.org/r1496545
Comment 6 Zdenek Kraus 2014-02-13 02:59:34 EST
This issue was tested on RHEL 6.5 x86_64 and i686 with following packages:

perl-qpid-0.22-7.el6
python-qpid-0.22-10.el6
python-qpid-qmf-0.22-26.el6
qpid-cpp-client-0.22-33.el6
qpid-cpp-client-devel-0.22-33.el6
qpid-cpp-client-devel-docs-0.22-33.el6
qpid-cpp-client-ssl-0.22-33.el6
qpid-cpp-debuginfo-0.22-33.el6
qpid-cpp-server-0.22-33.el6
qpid-cpp-server-devel-0.22-33.el6
qpid-cpp-server-ha-0.22-33.el6
qpid-cpp-server-ssl-0.22-33.el6
qpid-cpp-server-store-0.22-33.el6
qpid-cpp-server-xml-0.22-33.el6
qpid-java-client-0.22-5.el6
qpid-java-common-0.22-5.el6
qpid-java-example-0.22-5.el6
qpid-jca-0.22-1.el6
qpid-jca-xarecovery-0.22-1.el6
qpid-proton-c-0.6-1.el6
qpid-proton-c-devel-0.6-1.el6
qpid-proton-debuginfo-0.6-1.el6
qpid-qmf-0.22-26.el6
qpid-qmf-debuginfo-0.22-26.el6
qpid-snmpd-1.0.0-15.el6
qpid-snmpd-debuginfo-1.0.0-15.el6
qpid-tools-0.22-7.el6
ruby-qpid-qmf-0.22-26.el6


Issue was fixed.
-> VERIFIED

Note You need to log in before you can comment on or make changes to this bug.