forked from ClusterLabs/pacemaker
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathsecurity.txt
147 lines (119 loc) · 5.49 KB
/
security.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
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