qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chug Rolke" <cro...@redhat.com>
Subject Review Request 23322: Add ACL connection white/black lists to lock down hosts from which a user connects
Date Mon, 07 Jul 2014 22:18:35 GMT

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23322/
-----------------------------------------------------------

Review request for qpid and Andrew Stitcher.


Summary (updated)
-----------------

Add ACL connection white/black lists to lock down hosts from which a user connects


Bugs: QPID-4947
    https://issues.apache.org/jira/browse/QPID-4947


Repository: qpid


Description (updated)
-------

This patch adds:

1. ACL file syntax:
   acl result user create connection host=<host> | <host,host>

   group pepboys manny@QPID moe@QPID jack@QPID
   acl allow chuck create connection host=localhost
   acl allow chuck create connection host=[::1],[::1:0]
   acl deny  bob   create connection host=1.1.1.1
   acl deny  all   create connection host=10.0.0.0,10.255.255.255
   acl deny  all   create connection host=192.168.0.0,192.168.255.255
   acl deny  all   create connection host=localhost
   acl allow pepboys create connection host=pepboys.com
   acl deny  pepboys create connection host=127.0.0.1

2. The connection denial is implemented in ConnectionCounter where there is an existing approver.

3. Connection denial in implemented in two loops:
   a. Loop 1 is for user 'all'. This check could be placed at the socket level long before
the user is known.
   b. Loop 2 is for named users. This is a more normal check and should stay in ConnectionCounter
   These checks reject the connection before any of the max connection limit checks are tested.

4. AclReader intercepts the create connection rules and keeps them in separate lists for the
ConnectionCounter to check.
   These rules aren't checked with the acl Lookup functions.

5. The binary address range checks are done in SocketAddress.
   The implementation of the posix and windows changes to SocketAddress are identical.

The range matching logic has some non-obvious rules:

1. When a single host is named in the acl rule then that host may resolve to multiple addrinfo
structures. This is fine because the host data is duplicated into the (low, high) range pair
and the check is just for equality down the list.
2. When two hosts are named then each host must resolve to exactly one addrinfo struct. This
because some hosts may resolve to multiple IPv4 or IPv6 addresses and comparing ranges in
list like that is unpredictable. The host may resolve by name (as in example.com) or by numeric
IP but only one address is allowed.
3. It is presumed that the incoming host being matched against the acl ranges is a numeric
IP that resolves to one address.
4. Non-IP hosts are not subjected to nor denied by range checks.


Diffs (updated)
-----

  trunk/qpid/cpp/src/CMakeLists.txt 1608612 
  trunk/qpid/cpp/src/qpid/AclHost.h PRE-CREATION 
  trunk/qpid/cpp/src/qpid/AclHost.cpp PRE-CREATION 
  trunk/qpid/cpp/src/qpid/acl/Acl.h 1608612 
  trunk/qpid/cpp/src/qpid/acl/Acl.cpp 1608612 
  trunk/qpid/cpp/src/qpid/acl/AclConnectionCounter.h 1608612 
  trunk/qpid/cpp/src/qpid/acl/AclConnectionCounter.cpp 1608612 
  trunk/qpid/cpp/src/qpid/acl/AclData.h 1608612 
  trunk/qpid/cpp/src/qpid/acl/AclData.cpp 1608612 
  trunk/qpid/cpp/src/qpid/acl/AclReader.h 1608612 
  trunk/qpid/cpp/src/qpid/acl/AclReader.cpp 1608612 
  trunk/qpid/cpp/src/qpid/broker/AclModule.h 1608612 
  trunk/qpid/cpp/src/qpid/sys/SocketAddress.h 1608612 
  trunk/qpid/cpp/src/qpid/sys/posix/SocketAddress.cpp 1608612 
  trunk/qpid/cpp/src/qpid/sys/windows/SocketAddress.cpp 1608612 
  trunk/qpid/cpp/src/tests/AclHost.cpp PRE-CREATION 
  trunk/qpid/cpp/src/tests/CMakeLists.txt 1608612 

Diff: https://reviews.apache.org/r/23322/diff/


Testing (updated)
-------

A unit test for the Acl parsing and matching functions is added.
Tests for acl.py are coming.


Thanks,

Chug Rolke


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message