diff options
Diffstat (limited to 'doc/security.txt')
| -rw-r--r-- | doc/security.txt | 147 |
1 files changed, 147 insertions, 0 deletions
diff --git a/doc/security.txt b/doc/security.txt new file mode 100644 index 0000000..c211bf0 --- /dev/null +++ b/doc/security.txt @@ -0,0 +1,147 @@ +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 |