"Fossies" - the Fresh Open Source Software Archive

Member "pacemaker-Pacemaker-2.0.2/doc/security.txt" (6 Jun 2019, 5620 Bytes) of package /linux/misc/pacemaker-Pacemaker-2.0.2.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 Points of Entry
    2 ##################
    3 
    4 Inter CRM Messaging
    5 =======================
    6 Security relies on the existing systems in place for sending HA
    7 Messages.  The assumption here is that once a member node has been
    8 compromised, you've pretty much had it anyway.
    9 
   10 CRM Internal Messaging
   11 =======================
   12 Security relies on the existing systems in place for sending IPC
   13 Messages.  Remember, once a member node has been compromised, you've
   14 pretty much had it anyway.
   15 
   16 Admin client X, Y
   17 =======================
   18 Security replies on standard RPC mechanisms of hosts.allow/hosts.deny
   19 etc.  It is likely that this would be augmented by adding an identity
   20 store (leading candidates would be the CIB and /etc/passwd) and
   21 authorization mechanisms to the CRM RPC Server processes.
   22 
   23 To achieve a moderately sensible level of security granularity, the API
   24 should at least be split up into the following list of RPC Servers:
   25 
   26 cib_delete
   27 cib_update
   28 cib_create
   29 crm_admin
   30 
   31 
   32 Admin client Z
   33 =======================
   34 See: Inter CRM Messaging
   35 
   36 Potential Exploits
   37 =======================
   38 These exclude things like faking HA Messages, hacking IPC fifo's and for
   39 the moment packet sniffing of RPC requests.
   40 
   41 The "Measures" section is intended to contain measures to prevent the
   42 attack or to at least raise the bar for potential intruders.
   43 
   44 Exploit Class #1
   45 	Desc: Impersonate the DC
   46 	Requires: Access to the DC
   47 		  Ability to register with heartbeat as it is currently running[1]
   48 	Measures: 1, 2, 3, 4, 5
   49 
   50 Exploit Class #2
   51 	Desc: Impersonate the local CRMd
   52 	Requires: Access to the member node
   53 		  Ability to reconfigure and restart heartbeat
   54 	Measures: 4, 5, 7
   55 	Notes: This attack is pretty much limited to the local node (and any
   56 		  shared resources :cringe:) which is no more than they could
   57 		  do with access to the node anyway.
   58 
   59 Exploit Class #3
   60 	Desc: Impersonate a local CRMd client
   61 	Requires: Access to a member node
   62 	Measures: 1, 6
   63 
   64 Exploit Class #4
   65 	Desc: Rogue Admin client (Type Z)
   66 	Requires: Access to a member node
   67 		  Ability to construct valid XML message
   68 		  a) Ability to reconfigure and restart heartbeat, or
   69 		  b) Ability to register with Heartbeat with a currently unused
   70 		     client name
   71 	Measures: 8, ?
   72 	Notes: This is probably the second worst scenario, about all we could potentially do
   73 	       is implement behavioural pattern recognition and that is :definitely: not
   74 	       going to be in 1.0 :)
   75 
   76 Exploit Class #5
   77 	Desc: Rogue Admin client (Type X or Y)
   78 	Requires: Access to the CRM RPC API
   79 		  Access to a host with sufficient RPC permissions
   80 	Measures: 8, 9
   81 	Notes: This :is: the worst scenario, attackers don't even need access to a member
   82 	       node or modify/interrogate the Heartbeat config.  Again, about all we could
   83 	       potentially do is implement behavioural pattern recognition.
   84 
   85 Exploit Class #6
   86 	Desc: Data interception - Rogue Admin client (Type Y)
   87 	Requires: Access to the RPC API
   88 		  Knowledge of a current, valid and unchecked ticket ID[5]
   89 	Measures: 8, 9, 10
   90 
   91 Exploit Class #7
   92 	Desc: Malicious user (Using a Known Admin Client)
   93 	Requires: Access to a host with sufficient RPC permissions
   94 		  Access to an existing admin client
   95 		  a) Access to an identity that the RPC servers deem to have sufficient permissions, or
   96 		  b) Access to an admin client that passes a pre-defined set of credentials, not the users
   97 	Measures: 8, 9, 10, 11
   98 
   99 List of Measures
  100 =================
  101 Measure 1: As the CRMd, verify the "type" attribute when routing IPC messages from
  102 	   sub-systems and discard if it is not a response[2]
  103 
  104 Measure 2: As the CRMd, verfiy the "from" field on incoming messages and discard
  105 	   if it is not "admin" or "dc"
  106 
  107 Measure 3: As the CRMd, verfiy F_ORIG against known value for the DC.  Only the DC
  108 	   should be sending us messages[3]
  109 
  110 Measure 4: As Heartbeat, only allow clients registered as "crmd" to send messages
  111 	   with F_TYPE="CRM"
  112 
  113 Measure 5: Respawn the CRMd if it is stopped and drop out of the cluster if
  114 	   multiple HA clients are trying to register as "crmd"[4]
  115 
  116 Measure 6: As CRMd, cause Heartbeat to drop out of the cluster if multiple clients
  117 	   are trying to register as the same sub-system.
  118 
  119 Measure 7: As the CIB, detect multiple active registrations and shutdown
  120 	   when this is detected.
  121 
  122 Measure 8: Require the admin clients to provide a credential which must be matched
  123 	   against an identity store.[6][7]
  124 
  125 Measure 9: Configure RPC security appropriately
  126 
  127 Measure 10: Invalidate the ticket and the result set once the ticket has been used.
  128 
  129 Measure 11: Don't create admin clients that pass a pre-defined set of credentials
  130 
  131 [1] Shutting down Heartbeat to change permissions would mean the DC is
  132     assigned elsewhere anyway
  133 [2] Sub-systems other than the CRMs/DC should not be making requests
  134 [3] If not implemented, then this exploit would only require access to any
  135     member node
  136 [4] This is currently reported as an error and the second attempt is denied
  137 [5] It is envisioned that in the case of asynchronous RPC calls, that a
  138     "ticket" would be issued that the client would use to ask for a result,
  139     or perhaps set up a callback.  A second async call would be made to
  140     retrieve the result.  Synchronous RPC calls would internally use a
  141     different call that would block on this ticket until a result was
  142     available.
  143 [6] Depending on the type of client and where it takes its credentials from,
  144     this would either prevent unknown clients or unknown users accessing the
  145     CRM (at least until the ID store is hacked)
  146 [7] After the ID store is decided on, we obviously then need to consider the
  147     security surrounding it also