| Points of Entry |
| ################## |
| |
| Inter CRM Messaging |
| ======================= |
| Security relies on the existing systems in place for sending HA |
| Messages. The assumption here is that once a member node has been |
| compromised, you've pretty much had it anyway. |
| |
| CRM Internal Messaging |
| ======================= |
| Security relies on the existing systems in place for sending IPC |
| Messages. Remember, once a member node has been compromised, you've |
| pretty much had it anyway. |
| |
| Admin client X, Y |
| ======================= |
| Security replies on standard RPC mechanisms of hosts.allow/hosts.deny |
| etc. It is likely that this would be augmented by adding an identity |
| store (leading candidates would be the CIB and /etc/passwd) and |
| authorization mechanisms to the CRM RPC Server processes. |
| |
| To achieve a moderately sensible level of security granularity, the API |
| should at least be split up into the following list of RPC Servers: |
| |
| cib_delete |
| cib_update |
| cib_create |
| crm_admin |
| |
| |
| Admin client Z |
| ======================= |
| See: Inter CRM Messaging |
| |
| Potential Exploits |
| ======================= |
| These exclude things like faking HA Messages, hacking IPC fifo's and for |
| the moment packet sniffing of RPC requests. |
| |
| The "Measures" section is intended to contain measures to prevent the |
| attack or to at least raise the bar for potential intruders. |
| |
| Exploit Class #1 |
| Desc: Impersonate the DC |
| Requires: Access to the DC |
| Ability to register with heartbeat as it is currently running[1] |
| Measures: 1, 2, 3, 4, 5 |
| |
| Exploit Class #2 |
| Desc: Impersonate the local CRMd |
| Requires: Access to the member node |
| Ability to reconfigure and restart heartbeat |
| Measures: 4, 5, 7 |
| Notes: This attack is pretty much limited to the local node (and any |
| shared resources :cringe:) which is no more than they could |
| do with access to the node anyway. |
| |
| Exploit Class #3 |
| Desc: Impersonate a local CRMd client |
| Requires: Access to a member node |
| Measures: 1, 6 |
| |
| Exploit Class #4 |
| Desc: Rogue Admin client (Type Z) |
| Requires: Access to a member node |
| Ability to construct valid XML message |
| a) Ability to reconfigure and restart heartbeat, or |
| b) Ability to register with Heartbeat with a currently unused |
| client name |
| Measures: 8, ? |
| Notes: This is probably the second worst scenario, about all we could potentially do |
| is implement behavioural pattern recognition and that is :definitely: not |
| going to be in 1.0 :) |
| |
| Exploit Class #5 |
| Desc: Rogue Admin client (Type X or Y) |
| Requires: Access to the CRM RPC API |
| Access to a host with sufficient RPC permissions |
| Measures: 8, 9 |
| Notes: This :is: the worst scenario, attackers don't even need access to a member |
| node or modify/interrogate the Heartbeat config. Again, about all we could |
| potentially do is implement behavioural pattern recognition. |
| |
| Exploit Class #6 |
| Desc: Data interception - Rogue Admin client (Type Y) |
| Requires: Access to the RPC API |
| Knowledge of a current, valid and unchecked ticket ID[5] |
| Measures: 8, 9, 10 |
| |
| Exploit Class #7 |
| Desc: Malicious user (Using a Known Admin Client) |
| Requires: Access to a host with sufficient RPC permissions |
| Access to an existing admin client |
| a) Access to an identity that the RPC servers deem to have sufficient permissions, or |
| b) Access to an admin client that passes a pre-defined set of credentials, not the users |
| Measures: 8, 9, 10, 11 |
| |
| List of Measures |
| ================= |
| Measure 1: As the CRMd, verify the "type" attribute when routing IPC messages from |
| sub-systems and discard if it is not a response[2] |
| |
| Measure 2: As the CRMd, verfiy the "from" field on incoming messages and discard |
| if it is not "admin" or "dc" |
| |
| Measure 3: As the CRMd, verfiy F_ORIG against known value for the DC. Only the DC |
| should be sending us messages[3] |
| |
| Measure 4: As Heartbeat, only allow clients registered as "crmd" to send messages |
| with F_TYPE="CRM" |
| |
| Measure 5: Respawn the CRMd if it is stopped and drop out of the cluster if |
| multiple HA clients are trying to register as "crmd"[4] |
| |
| Measure 6: As CRMd, cause Heartbeat to drop out of the cluster if multiple clients |
| are trying to register as the same sub-system. |
| |
| Measure 7: As the CIB, detect multiple active registrations and shutdown |
| when this is detected. |
| |
| Measure 8: Require the admin clients to provide a credential which must be matched |
| against an identity store.[6][7] |
| |
| Measure 9: Configure RPC security appropriately |
| |
| Measure 10: Invalidate the ticket and the result set once the ticket has been used. |
| |
| Measure 11: Don't create admin clients that pass a pre-defined set of credentials |
| |
| [1] Shutting down Heartbeat to change permissions would mean the DC is |
| assigned elsewhere anyway |
| [2] Sub-systems other than the CRMs/DC should not be making requests |
| [3] If not implemented, then this exploit would only require access to any |
| member node |
| [4] This is currently reported as an error and the second attempt is denied |
| [5] It is envisioned that in the case of asynchronous RPC calls, that a |
| "ticket" would be issued that the client would use to ask for a result, |
| or perhaps set up a callback. A second async call would be made to |
| retrieve the result. Synchronous RPC calls would internally use a |
| different call that would block on this ticket until a result was |
| available. |
| [6] Depending on the type of client and where it takes its credentials from, |
| this would either prevent unknown clients or unknown users accessing the |
| CRM (at least until the ID store is hacked) |
| [7] After the ID store is decided on, we obviously then need to consider the |
| security surrounding it also |