1 denise.eckstein 1.2 <html>
2 <head>
3 <meta http-equiv="Content-Language" content="en-us">
4 <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
5 <title>PEP</title>
6 <link rel="stylesheet" href="http://www.opengroup.org/stylesheets/info1+margins.css">
7 <style><!--
8 -->
9 </style>
10 </head>
11 <body bgcolor="#FFFFFF">
12 <h1> <font color="#000000">Pegasus Security Implementation Guidelines</font></h1>
13 <hr>
14 <h2><font color="#000000">Problem Statement</font></h2>
|
15 kumpf 1.3 <p><font color="#000000">Open Pegasus has a challenging role. It provides a portal
16 for users and programs to access a wide variety of information on a system.
17 Pegasus is responsible for user authentication and provides a framework for
18 the provider authors to authorize specific read and write operations on the
19 server. Managing the resulting "trust delta" (the difference between
20 what the provider <em>could </em>do in its current execution context, vs. what
21 a given user is <em>authorized</em> to do) is hard. The bigger the trust delta,
22 the greater the incentive to "break in" past authorizations in providers
23 to "get to" a super-user/administrator execution context(or to the
24 context of a user that can do something the authenticated user isn't authorized
25 to do). Though the OpenPegasus 2.5 feature, <strong>"run-as-requestor,"</strong>
26 does provide a way to lower the risk to a given provider that takes advantage
27 of the run-as-requestor context, there are still risks for the providers that
28 decide to run at elevated privilege (defined as when the execution context has
29 more permissions/abilities than the authorized users... hard to avoid when the
|
30 denise.eckstein 1.2 execution is not <em>as</em> the authorized user).</font></p>
|
31 kumpf 1.3 <p><font color="#008000">Pre-2.5 implementations of OpenPegasus do not change
32 the user-context (effective-user) of the provider from that of the CIMOM. Thus,
33 when Pegasus is used on the majority of platforms (that don't provide intra-thread
34 protections and/or work in a multi-user environment) a provider can, through
35 mistake or intent, easily affect the security of the CIMOM and other providers.
|
36 denise.eckstein 1.2 </font></p>
37 <h2><font color="#000000">Requirements, Constraints or Assumptions</font></h2>
|
38 kumpf 1.3 <p>Most of the risk of failing to follow the guidelines below are only present
39 when code is not run as the authenticated user (whether that code be in the
40 provider or the client) or in deployments for which the concept of authentication
41 isn't used (i.e.: SNMP-public info). Even for more limited deployments, many
|
42 denise.eckstein 1.2 of the problems below can still cause potential crashes/denial of service conditions.</p>
43 <h2><font color="#000000">Definitions:</font></h2>
|
44 kumpf 1.3 <p>Elevated code: a difference between the actions that the logged in user is
45 authorized to perform, and the execution context of the running program.
46 This "trust delta" must then be managed by the code to ensure that
47 the user doesn't perform more actions than they are authorized either directly
48 or through side-effect. For example, a process run as the UID of the authenticated
49 user is thus said to be "non-elevated." A process running as
50 administrator on behalf of a "non-administrator" user, would be called
|
51 denise.eckstein 1.2 elevated.</p>
|
52 kumpf 1.3 <p>Privilege: The collection of actions a process or user is not prevented from
53 doing. An "administrator"/root user is said to be full privilege
54 with respect to a system since that execution context does not prevent any action
|
55 denise.eckstein 1.2 on the system.</p>
|
56 kumpf 1.3 <p>Trust: The degree to which an actor that is interacting with the component
57 under consideration is believed to behave non-maliciously. For example,
58 an arbitrary user on the Internet has no 'trust," a junior operator or
59 administration is trusted to no attempt malicious activity, but may accidentally
60 attempt damaging actions. Root/Administrator code is trusted to behave
|
61 denise.eckstein 1.2 correctly.</p>
|
62 kumpf 1.3 <p>Security Testing: Non-functional testing that centers around behavior in the
63 presence of malicious use. Examples includes testing for crashes or security
64 side-effects in the presence of overly long inputs, special character inputs,
|
65 denise.eckstein 1.2 high-system load, and network storm environments.</p>
|
66 kumpf 1.3 <p>Security Side Effect: Applications often, in accomplishing their goals, perform
67 actions beyond those visible to the user. Examples include writing temporary
68 files, or clearing or requesting memory. Since this behavior is not specified
69 in the functional requirements, it is often not tested. This "side
70 effect" behavior is often the behavior that a malicious user attempts to
71 leverage when trying to gain privilege. Examples include exploiting race
72 conditions where a temporary file is momentarily world writeable, before it
73 is chmod-ed. This window is an opportunity for a malicious user to insert
|
74 denise.eckstein 1.2 data that can change the behavior of the application.</p>
75 <h2><font color="#000000">References:</font></h2>
76 <p>Architecture: <a href="http://www.opengroup.org/security/secarch.htm"> http://www.opengroup.org/security/secarch.htm</a></p>
77 <p>Books and References (not endorsed by Opengroup or partners): </p>
78 <ul>
79 <li><a href="http://www.oreilly.com/catalog/securecdng/"> http://www.oreilly.com/catalog/securecdng/</a></li>
80 <li><a href="http://www.oreilly.com/catalog/puis3/"> http://www.oreilly.com/catalog/puis3/</a></li>
|
81 kumpf 1.3 <li><a href="http://www.securityfocus.com/infocus/1596"> http://www.securityfocus.com/infocus/1596</a>
|
82 denise.eckstein 1.2 </li>
83 </ul>
84 <h2><font color="#000000">Proposed Solution </font></h2>
85 <h3><font color="#000000">General Implementation Guidelines: </font></h3>
|
86 kumpf 1.3 <h4><font color="#000000">Code that doesn't adhere to the following guidelines
87 in elevated code should be considered a bug, including providers not running
88 as-requestor. it is a best-practice to follow the following guidelines for all
|
89 denise.eckstein 1.2 code. </font></h4>
90 <ol>
|
91 kumpf 1.3 <li> <u>Avoid buffer overflow vulnerabilities</u> in your code (hackers use
|
92 denise.eckstein 1.2 to insert arbitrary code) <br>
|
93 kumpf 1.3 Buffer overflows in network-accessible software cause the most, and some believe,
94 the majority, of software vulnerabilities. Since Pegasus is written in C/C++,
95 it is especially susceptible to buffer overflows. Strongly consider using
96 a static tool like Flawfinder or RATS to look for common problems. Dynamic
97 tools can also be used but only identify problems when the overflow actually
98 happens vs. finding potential overflows. The susceptibility stems from a lack
99 of bounds checks in C++ and C. Problematic functions include strcpy, sprintf,
|
100 denise.eckstein 1.2 strcat, gets, and strlcat.</li>
101 <ul>
102 <li> References:<br>
103 <ul>
|
104 kumpf 1.3 <li> Smashing the stack for fun and profit, <a href="http://www.phrack.com/show.php?p=49">http://www.phrack.com/show.php?p=49</a>
|
105 denise.eckstein 1.2 <br>
|
106 kumpf 1.3 <li> Heap Overflows: <a href="http://www.phrack.org/phrack/57/p57-0x08%20">http://www.phrack.org/phrack/57/p57-0x08</a>
|
107 denise.eckstein 1.2 <br>
108 </ul>
109 </li>
110 </ul>
|
111 kumpf 1.3 <li> <u>Avoid format string vulnerabilities</u> in your code (hackers use to
|
112 denise.eckstein 1.2 read or insert arbitrary code)<br>
|
113 kumpf 1.3 Format strings define the format and types of program variables that are substituted
114 into an input or output string. Exploitation of format strings occurs when
115 functions that require a format string are coded with a variable, and that
116 variable is not validated. For example the following is vulnerable code: printf(string_from_untrusted_user)
117 as the user can supply the format string, and read or overwrite (using %n)
|
118 denise.eckstein 1.2 arbitrary data. Each developer must: </li>
119 <ul>
120 <li> Use functions with a strict format string argument.</li>
|
121 kumpf 1.3 <li> Check the input parameter data for format strings before assigning them
|
122 denise.eckstein 1.2 to variables.</li>
|
123 kumpf 1.3 <li>Always validate that the input parameter data does not contain any program-specific
|
124 denise.eckstein 1.2 format characters before assigning the input data to variables.</li>
125 <li> Always check the return codes of library functions for failure.<br>
126 </li>
127 </ul>
|
128 kumpf 1.3 <li><u>Adhere to the general, good programming practices</u>:
|
129 denise.eckstein 1.2 <ol>
130 <li> Always have people other than the coder review the code.</li>
|
131 kumpf 1.3 <li> Always have people other than the coder develop tests and test the
|
132 denise.eckstein 1.2 end product.</li>
|
133 kumpf 1.3 <li> Check return codes from system or library calls, and handle errors
|
134 denise.eckstein 1.2 or exceptions gracefully.</li>
|
135 kumpf 1.3 <li>Keep your code simple: simple code decreases the risk of defects; complex
|
136 denise.eckstein 1.2 code increases the risk of defects.</li>
137 <li> Don't use uninitialized variables.</li>
|
138 kumpf 1.3 <li> Use symbolic constants (such as #define) to minimize typos and improve
|
139 denise.eckstein 1.2 code maintainability.</li>
|
140 kumpf 1.3 <li> Use temporary files with care. Do not create temporary directories
141 or files from your program that are world writeable. Limit the permissions
142 to what is needed by the program. Clean up temporary files or directories
|
143 denise.eckstein 1.2 when you are finished using them.</li>
|
144 kumpf 1.3 <li>Do not put sensitive information in log files. For example, do not print
145 social security numbers, passwords, credit card numbers, or any other
146 sensitive or personal information for debugging purposes in the log files.
147 Sometimes such information shows up in the web browser in case of exceptions
|
148 denise.eckstein 1.2 or application failure.</li>
|
149 kumpf 1.3 <li> Enforce strong password policies and a delay on failed logins. This
150 helps to prevent unauthorized access to private data. See libpam for a
|
151 denise.eckstein 1.2 good way to implement this.</li>
|
152 kumpf 1.3 <li>
153 <p>Validate input to the program or system before processing the input.
154 Test to see if the input is the proper type of data and in the range
155 of acceptable or expected values and test both upper and lower bounds.
156 For example, if you are reading in a year value (int), and you have
|
157 denise.eckstein 1.2 already checked for buffer overflow and format strings:</p>
|
158 kumpf 1.3 <blockquote>
|
159 denise.eckstein 1.2 <p>Correct: if 0 <= year <= 3000 then (accept input and process)</p>
160 <p>Unsafe: if year <= 3000 then (accept input and process)</p>
|
161 kumpf 1.3 <p>The vulnerability of the unsafe example is that if someone were to
162 return a value of -32769, then they could intentionally stop or corrupt
163 a procedure. If the language which you are using does not enforce
164 strong types, then a type check should also be performed before accepting
|
165 denise.eckstein 1.2 the input.</p>
166 </blockquote>
167 </li>
168 </ol>
169 </li>
170 <li> <u>Use the principles of least and necessary privilege</u>.<br>
|
171 kumpf 1.3 Only grant the minimum set of privileges required to perform an operation,
172 and grant these privileges for the minimum required amount of time. For example,
173 if a provider needs to modify both mail queues and print spools, don't run
174 the application as root; instead, use /etc/logingroup or other facilities
175 to give the application the privileges which it needs, but not more privileges
|
176 denise.eckstein 1.2 than it needs. <br>
177 </li>
|
178 kumpf 1.3 <li> <u>Use SSL securely</u>:
179 <p> Please refer to the OpenSSL documentation for usage. Pegasus libraries
180 help with some but not all functions necessary for certificate management
|
181 denise.eckstein 1.2 and usage.</li>
182 <li> <u>Handle race conditions securely</u><br>
|
183 kumpf 1.3 Race conditions occur when two or more processes access a shared resource
184 in an order that was not expected by the program. Unordered access to resources
185 is common in multitasking environments, and is mostly associated with either
186 Signal Handlers or File Handling. For example, if a program "A"
187 checks to see if a file exists before writing, but a program "B"
188 creates a link after the check, but before the write, "A" may inadvertently
189 overwrite the link destination with the permissions associated with "A".
190 This can be a security problem if "A" has different permissions
|
191 denise.eckstein 1.2 than "B."</li>
|
192 kumpf 1.3 <li> <u>Use secure defaults when possible, or clearly document when they aren't
|
193 denise.eckstein 1.2 used</u> </li>
194 <li> <u>Design Securely</u><br>
|
195 kumpf 1.3 Design your code so that as little as possible runs as a privileged user.
196 All privileged user code (especially if it listens on a network or executes
197 on behalf of other users) should be inspected very thoroughly, so it should
198 be short and simple. Each module of code should have a clean interface for
199 other modules to use and a well-defined perimeter around each module.
200 Additional details can be found at: <a href="http://www.joeyoder.com/papers/patterns/Security/appsec.pdf">
|
201 denise.eckstein 1.2 Architectural Patterns for Enabling Application Security</a> <font size="-4">(http://www.joeyoder.com/papers/patterns/Security/appsec.pdf)</font></li>
202 <li> <u>Test for security </u>(use both positive and negative tests)<br>
|
203 kumpf 1.3 "Positive tests"verify that the functionality of the product works as specified.
204 "Negative tests"attempt to subvert the security of the system, and are often
205 overlooked when testing software. Spend some time thinking like a hacker and
206 trying to break your system. Always test boundary conditions or corner cases
207 for values of data, size of data, and type of data. Many common bugs are related
208 to this. Sometimes this type of bug may result in wrong information being
209 retrieved from the database instead of failing gracefully. Attempt to exploit
|
210 denise.eckstein 1.2 the system with buffer overflow and format string attacks.</li>
211 <li> <u>Don't bundle private copies of security code</u><br>
|
212 kumpf 1.3 Security code (especially highly scrutinized open-source code) is likely to
213 have security bulletins issued against it. When such security bulletins are
214 inevitably issued against code you depend on, you don't want to have to issue
215 a bulletin against your product also. If you put a dependency in your code
216 to a standard distribution of a component which you need (for example OpenSSL),
217 rather than embedding a private copy, then whenever a security bulletin is
218 issued against it, you won't have to reissue the bulletin after repacking
|
219 denise.eckstein 1.2 the fix for your private copy. <br>
220 </li>
221 </ol>
222 <h4><font color="#000000">General Coding Best-Practices:</font></h4>
223 <ol>
|
224 kumpf 1.3 <li> <u>Avoid implementing security functionality</u>: Making security claims
225 in your documentation (beyond the implied security claims of authentication
226 and authorization done by the operating system) can increase your risk of
227 having a security defect. This is because any of those claims that are not
228 fully implemented or enforced is by definition a security defect and requires
229 an expedited fix and a security bulletin to announce that fix. Reuse of tried-and-tested
230 code, that has been used in a security context is always a better choice.
231 Never implement a random number generator or cryptographic algorithm unless
|
232 denise.eckstein 1.2 you're a cryptographer by profession. You will almost certainly get it wrong.<br>
|
233 kumpf 1.3 You should always, however, document your security behavior.
|
234 denise.eckstein 1.2 </li>
|
235 kumpf 1.3 <li><u>Duplicating authorization code</u>: Related to risk #1, every provider
236 has the risk of authorization related defects because the authorization done
237 in each provider is a duplication of the kernel authorization code. However,
238 you can still decrease your risk by using common API's. For example, many
239 providers will need a way to tell if the authenticated user should have access
240 to a given file. The code which does this needs to check the user id, group
241 ids of the file in question and all of its parent directories. Any defect
242 in this code could easily be a security defect and would need to be fixed
243 in every copy of that code. For this reason it is imperative that this logic
244 exists in only one place and that your provider uses that copy. Do not try
245 to replicate this complex logic in your own provider, unless you are the single
|
246 denise.eckstein 1.2 owner of that code. </li>
|
247 kumpf 1.3 <li>WBEM provider/client combinations: Writing a WBEM provider that is also
248 a WBEM client (makes requests of other providers) has security risks/challenges.
249 There are two subcategories of this risk/challenge:
|
250 denise.eckstein 1.2 <ol>
|
251 kumpf 1.3 <li>using the connectLocal() API uses the UID of the running process to
252 do authentication. Thus, the provider initiating the request must ensure
253 authorization of the other provider's data before making the request.
254 (This is another example of Risk 2, multiple copies of authorization code)
255 One feasible way to do this is to check that the user is a privileged
256 user before calling the other provider (in which case the UID matches
|
257 denise.eckstein 1.2 the running process)</li>
|
258 kumpf 1.3 <li> Using the connect() API has additional complexities. Credentials must
259 be somehow passed into the provider and then handled appropriately. Also,
260 there are additional client responsibilities as far as certificate validation
261 and testing, and the consequences are more severe because the client is
|
262 denise.eckstein 1.2 running with elevated privileges</li>
263 </ol>
264 </li>
265 </ol>
266 <h3> <font color="#000000">Provider Implementation Guidelines </font></h3>
|
267 kumpf 1.3 <h4> <font color="#000000">Code that doesn't following the following guidelines
|
268 denise.eckstein 1.2 in providers running at elevated-privilege should be considered a bug.<br>
|
269 kumpf 1.3 Code in providers running as-requestor can consider the following as general
|
270 denise.eckstein 1.2 best practice.</font></h4>
271 <ol>
|
272 kumpf 1.3 <li> <u>Check the username/uid and execute every method as if it was running
273 as that user</u> (i.e. had the OS kernel or authorization service done the
|
274 denise.eckstein 1.2 authorization).<br>
|
275 kumpf 1.3 By checking each operation they perform, and ensuring those operations, when
276 performed on behalf of a non-privileged user, do not have security side-effects.
277 Any discrepancy between OS authorizations done by the kernel and that done
278 by the provider that is not part of documented behavior is a security defect.
279 If the user does not have the privileges to perform the requested operation
|
280 denise.eckstein 1.2 the Provider must throw CIMAccessDeniedException.</li>
281 <li> <u>Keep your design/provider simple.</u> <br>
|
282 kumpf 1.3 While this is difficult to quantify, it is important to minimize the amount
283 of code running as a privileged user. As a general guideline, if you have
284 significant lines of code running with elevated privilege, the likelihood
285 of a security defect is high. Remember that defects in elevated privilege
286 code is a potential security defect, so all of this code must be straightforward
287 and easy to review based on the principles mentioned in the General Coding
288 principles above. The likelihood of a defect not being found is proportional
|
289 denise.eckstein 1.2 to the amount and complexity of the code. </li>
|
290 kumpf 1.3 <li><u>Provider must not use any calls such as setuid or setting environment
291 variables (i.e. PATH) that would alter the state of the process running the
|
292 denise.eckstein 1.2 CIM Server.</u> <br>
293 This could cause unexpected results for other providers or threads.</li>
294 <li><u>Provider must document property authorizations</u>. <br>
|
295 kumpf 1.3 Specifically, the provider should describe which data elements they make available
296 for reading, which system changes they are capable of making, and which users
|
297 denise.eckstein 1.2 will be able to read those elements and make those changes.</li>
298 <li><u>Provider must check all untrusted input for validity.</u> <br>
|
299 kumpf 1.3 While the CIM Server ensures that the input is a valid CIM request, the provider
300 is responsible for validating that the CIM request does not cause any side
301 effects by ensuring that the input strings contain only expected characters
302 and that values are within an expected range. Examples of input data that
303 must be checked include directory or file names, data within files that are
|
304 denise.eckstein 1.2 read by the provider, and data returned from system calls.</li>
305 <li><u>Provider must execute stress tests</u>.<br>
|
306 kumpf 1.3 These include operation in the presence of multiple interacting provider requests.
307 Based on a white box analysis of your provider, identify ways in which testing
308 could stress your provider. For example, sending large input strings, a large
309 number of simultaneous requests, requests including out-of-bounds data, or
310 ensuring that every branch is covered are just a few ways that you could stress
311 your product to find potential defects. By exploring the way your provider
312 fails, you can look for side effects that might lead to "infinite"
313 resource requests, overwritten data, or other anomalies that could cause a
|
314 denise.eckstein 1.2 denial-of-service or reveal a side-effect that can be leveraged as an exploit.</li>
315 <li><u>Design your provider to expect belligerent input</u>. <br>
|
316 kumpf 1.3 For example, have a common method that validates all CIM requests and ensure
317 that that method gets called for every request. The method should assume that
318 input is invalid unless it matches a specific format and specific bounds are
319 checked. Also, if your provider allocates any memory buffers or writes to
320 any file based on user input, all error conditions (out-of-memory, disk full,
321 file is a symbolic link/device file/directory instead of the expected format,
322 buffer/array too small for data, etc.) should be checked and all of this should
|
323 denise.eckstein 1.2 be enforced in a common place.</li>
|
324 kumpf 1.3 <li><u>Do not allow group or world-write access </u>to your shared library,
325 any other executable code, configuration files, or any parent directory of
|
326 denise.eckstein 1.2 any of the above. <br>
|
327 kumpf 1.3 Although only a privileged user ought to be able to create the symbolic links
328 or shortcuts to the provider shared library in the designated WBEM provider
329 library directory, the actual provider shared library can be placed in any
330 directory. A provider must ensure that their shared libraries are protected
331 in such a way that only a privileged user can modify or delete the shared
|
332 denise.eckstein 1.2 library or the directory where the shared library is located.</li>
|
333 kumpf 1.3 <li><u><font color="#008000">Don't bypass authentication</font></u><font color="#008000">:
334 To avoid damaging CIMOM and other-providers' security, providers should not
335 bypass CIMOM authentication steps in communicating to other providers or the
336 CIMOM (manipulating CIMOM-handle userid) and instead use CIMClient in accordance
337 with "General-Client Best Practices" section. In cases where the
338 Pegasus use-model does rely on platform-native inter-thread protections, a
339 future protection algorithm may have to be implemented in OpenPegasus that
340 ensures an unchanged state of the operation context. Note however that, In
341 Pegasus 2.5, if a provider uses run-as-requestor, that will ensure the provider
342 runs in the right user-context, and cleans up the interface to that provider
|
343 denise.eckstein 1.2 to ensure it doesn't skip inter-provider authentication. </font><br>
344 </li>
345 </ol>
346 <h4><br>
347 <font color="#000000">Provider Best-Practices:</font></h4>
348 <ol>
|
349 kumpf 1.3 <li><u>Use "UserContext registration" setting, present in Open Pegasus
|
350 denise.eckstein 1.2 2.5 and later</u>: <br>
|
351 kumpf 1.3 In Pegasus 2.5 and after, you should strongly consider registering your provider
352 to run as requestor context, or if not available, use Windows "impersonation"
353 or fork a correct-user-running process. For providers in versions prior to
354 2.5, you may want to consider implementing your own out of process provider,
355 to avoid the risks of running at elevated privilege. For those that must run
|
356 denise.eckstein 1.2 privileged: </li>
357 <ul>
|
358 kumpf 1.3 <li><u>Check that the authenticated username provided by CIM matches the effective
359 user id</u> of the running process. For Pegasus 2.4 and prior, this means
360 that only the privileged user would be able to use your provider. The general
361 property is that if you are not elevating privilege (running on behalf of
362 a different user), then the likelihood of a security defect is greatly decreased.
363 Making your code more general may mean less work in the future when non-privilege-elevated
364 providers are able to run with the correct user-id. Even in the model
365 where Pegasus is run under a non-privileged user, there is a delta in "trust"
366 between the different users. This still represents some, though not
367 as much, risk as deploying a run-as-administrator Pegasus. There is
368 an opportunity to improve Pegasus to better support fully protecting this
369 use model, though this is less urgent than protecting the higher risk associated
|
370 denise.eckstein 1.2 with an administrator running CIM server.</li>
|
371 kumpf 1.3 <li><u>Recommend configuring the WBEM users group (ref: PEP 142)</u>: For
372 Pegasus versions prior to 2.5, and subsequent, customers can configure a
373 specific group of users who has access to WBEM providers. This allows customers
374 to choose a tradeoff between security risk and ease-of-setup. Since every
375 provider runs with elevated privilege, the risk of security defects is high.
376 Thus, it is advised that customers configure this group of WBEM users to
377 only allow access to users who are trusted not to be malicious. If you also
378 do not run by default, this information can be in your initial setup documentation
379 so that it gets to all of your customers. This can greatly decrease your
380 risk of having a security defect, because all malicious activities can be
|
381 denise.eckstein 1.2 potentially ruled out.</li>
382 </ul>
|
383 kumpf 1.3 <li><u>Providers should consider the tradeoff between default installation/registration
384 and optional</u>: An optional installation of a component (as part of
385 an OS or software package) gives customers a choice as to whether or not to
386 limit their interface/exposure, and maintenance/patch burden. Your provider
387 likely meets a real need for many customers, but there are also customers
388 who do not need the functionality you provide. There are many customers who
389 would prefer less patching/update cost and decreased security risk (risk is
390 added whenever there is a new interface) versus the functionality that your
391 product provides. Although technically this doesn't decrease the risk of having
392 a security defect, it can give you more options for interim workarounds until
393 you can get a critical fix out, and fewer customers would be affected by any
394 given defect. Provider writers and bundlers should consider these benefits
|
395 denise.eckstein 1.2 and weigh those against the bundling benefits of mandatory inclusion.</li>
|
396 kumpf 1.3 <li><u>Log important events, such as unauthorized requests</u>: This can help
397 a customer track down a potential intrusion as well as debug problems. Do
398 not include confidential information, such as passwords, in the log. Ensure
399 that the confidentiality of information stored in the log is commensurate
400 with access to the log. It is recommended that you use a common logging facility,
401 such as syslog. Syslogd takes care of things like log rotation, etc. and the
|
402 denise.eckstein 1.2 administrator already knows where to look for your logs.</li>
|
403 kumpf 1.3 <li><u>When making system changes, use platform security checks where possible
404 vs. rewriting your own authorization code</u>: Duplicating authorization code
|
405 denise.eckstein 1.2 at least doubles the work and is more error-prone.</li>
406 </ol>
407 <h3> <font color="#000000">Client Implementation Guidelines:</font></h3>
|
408 kumpf 1.3 <p> Note: In general, these are the responsibility of the applications invoking
409 CIM client libraries to the extent that the client libraries don't yet provide
|
410 denise.eckstein 1.2 the direct support.</p>
|
411 kumpf 1.3 <h4> <font color="#000000">Client code that doesn't follow these guidelines should
|
412 denise.eckstein 1.2 be considered a bug:</font></h4>
413 <ol>
|
414 kumpf 1.3 <li><u>Use SSL as<a> follows in your remote production client. Though WBEM does
|
415 denise.eckstein 1.2 provide libraries to help, client behavior is the client's responsibility:</a></u></li>
|
416 kumpf 1.3 <li><u>Protect the Keystore and Truststore for remote production clients</u>:
|
417 denise.eckstein 1.2 <ul>
|
418 kumpf 1.3 <li>Use proper file and directory permissions to protect keystore and truststore
|
419 denise.eckstein 1.2 files. </li>
|
420 kumpf 1.3 <li>If your applications are importing the servers' certificate to a truststore,
421 you must ensure that the user validates the certificates received before
|
422 denise.eckstein 1.2 adding them to a truststore or keystore.</li>
423 <li>Do not use less than 1024 bit keysize to create keystores.</li>
|
424 kumpf 1.3 <li>Keystores/truststores should not be readable or writeable by anyone
|
425 denise.eckstein 1.2 other than the user who owns them.</li>
426 </ul>
427 </li>
|
428 kumpf 1.3 <li><u>General programming standards</u>
|
429 denise.eckstein 1.2 <ul>
|
430 kumpf 1.3 <li>Do not use world-writeable files or directories (including /tmp and
431 /var/tmp). Make sure all credentials (passwords/certificates) are
|
432 denise.eckstein 1.2 readable only by their owner.</li>
|
433 kumpf 1.3 <li>Do not cache passwords unless directed to do so by the user. The
434 user should be aware that their password is being stored permanently on
|
435 denise.eckstein 1.2 the client machine.</li>
|
436 kumpf 1.3 <li>Do not pass passwords as an option on the command-line in non-windows
437 clients. Command-lines are visible to all users on the system in
|
438 denise.eckstein 1.2 some operating systems.</li>
439 </ul>
440 </li>
441 </ol>
442 <h4><font color="#000000">General client best-practices:</font></h4>
443 <ol>
|
444 kumpf 1.3 <li><u>Limit access to client data</u>: Each user of a WBEM client should have
445 his/her own WBEM client instance. The WBEM client process should run
|
446 denise.eckstein 1.2 as the correct user on the client machine.</li>
|
447 kumpf 1.3 <li><u>Local vs. Remote Requests and Username/Password Authentication</u>: Use
448 the connectLocal() API call to connect to the CIM server whenever possible.
449 To use this API call properly, the process must run with the correct userid
|
450 denise.eckstein 1.2 <br>
451 <br>
|
452 kumpf 1.3 <font face="Courier">Warning: For Pegasus earlier than 2.5, doing client
453 operations from a CIM provider significantly increases your security risk
454 if the initial client requester was not running as root. This is due
455 to the implementation which runs the provider in the CIM Server process space
456 with a single, often privileged, user so the provider it connects to will
457 be unable to use built-in authentication. Providers issuing WBEM client
458 operations must adequately address the security risk. A few alternatives
459 to address the security concern are: 1) ensure (either at design time or at
460 runtime in the provider) that the user is authorized to access the data being
461 requested from the second provider, and 2) the provider could launch another
462 process and issue the request to the second provider as the intended user.</font>
|
463 denise.eckstein 1.2 <p>Background on connectLocal(): <br>
|
464 kumpf 1.3 A local connection mechanism exists for clients to communicate with the
465 CIM Server on the same system. The connectLocal() function is used for this
466 purpose, and does not take any arguments. In the case where PEGASUS_LOCAL_DOMAIN_SOCKET
467 is defined, (default on all but Windows, as currently the Windows connectLocal
468 authentication is not functional as of 2.5) the user ID passed to the provider
469 is that of the process in which the client program is running. The CIM Server
470 verifies that the user ID of the request is indeed that of the requesting
471 process. Namespace authorization, if enabled, is still performed.
472 When the client must be able to connect to a CIM Server on a remote system,
473 or when it must be able to specify a different user than that of the process,
474 it must use the connect() function. This function allows a hostname and
475 port number to be specified, as well as a username and password. If
476 you need to use the connect() API, the WBEM client has several responsibilities
477 to ensure correct authentication and to protect confidential information.
478 Because connectLocal() does not use SSL, these guidelines only apply to
479 the connect() interface. Using connectLocal() bypasses these requirements
480 except where PEGASUS_LOCAL_DOMAIN_SOCKET is not defined. In that case,
481 it behaves like connect(), using HTTPS and/or HTTP as defined in Pegasus
|
482 denise.eckstein 1.2 settings.<br>
483 </li>
|
484 kumpf 1.3 <li><u>General programming standards</u>
|
485 denise.eckstein 1.2 <ul>
|
486 kumpf 1.3 <li>Design for belligerent input. A separate module should be responsible
487 for validating all input before taking any action. Invalid input
488 should be discarded. If you client has high availability requirements,
|
489 denise.eckstein 1.2 deal with invalid input quickly to avoid Denial of Service attacks.</li>
|
490 kumpf 1.3 <li>Use a strongly-typed language if possible (i.e. Java). If your
491 client is in C++, then use a security scanner such as RATS (<a href="http://www.securesoftware.com/resources/download_rats.html">http://www.securesoftware.com/resources/download_rats.html</a>)
492 to identify problem areas and follow the recommendations. (Note:
493 code scanners such as these tend to make a lot of recommendations, so
494 plan on adequate time for manual analysis and focus on your input validation
|
495 denise.eckstein 1.2 module.)</li>
|
496 kumpf 1.3 <li>Do not use world-writeable files or directories (including /tmp and
497 /var/tmp). Make sure all credentials (passwords/certificates) are
|
498 denise.eckstein 1.2 readable only by their owner.</li>
|
499 kumpf 1.3 <li>Do not cache passwords unless directed to do so by the user. The
500 user should be aware that their password is being stored permanently on
|
501 denise.eckstein 1.2 the client machine.</li>
|
502 kumpf 1.3 <li>Do not pass passwords as an option on the command-line on non-windows
503 systems. Command-lines on non-windows systems are visible to all
|
504 denise.eckstein 1.2 users on the system.</li>
|
505 kumpf 1.3 <li>If possible, do not make any server-initiated changes on the client
506 system. Doing so increases the risk of security vulnerabilities
|
507 denise.eckstein 1.2 in your client, and a security reviewer should be consulted.</li>
|
508 kumpf 1.3 <li>If possible, log events of interest, including certificate warning messages
509 and invalid responses sent from the server. Doing so increases the ability
510 of a user or system administrator to track down unauthorized actions.
511 Use either a user-specific logfile or syslog. Be sure to check for
|
512 denise.eckstein 1.2 corner cases like disk-space limitations.</li>
|
513 kumpf 1.3 <li>HTTP Indications should only be used to send confidential information
514 in environments where the risk of exposure to man-in-the-middle type attacks
515 is low (e.g. where a rogue CIM Listener could intercept indications).
516 If your listener expects to receive confidential information, be sure
517 to document that this information will be visible to anyone on the network
|
518 denise.eckstein 1.2 clearly to the customer initiating the subscription.</li>
519 </ul>
520 </li>
|
521 kumpf 1.3 <li><u>Security Testing Guidelines</u>
|
522 denise.eckstein 1.2 <ul>
|
523 kumpf 1.3 <li>Run the following tests, and ensure that your client gives a useful
524 error message and does not crash. Crashes on strange and unexpected
525 input are, at a minimum, a denial-of-service, and often represent buffer
526 or format-string vulnerabilities.:
|
527 denise.eckstein 1.2 <ul>
|
528 kumpf 1.3 <li>CIM server you are connecting to is not available (disabled or network
|
529 denise.eckstein 1.2 problems)</li>
530 <li>CIM server responds with an extremely large response</li>
|
531 kumpf 1.3 <li>CIM server or provider responds with invalid characters or garbage
|
532 denise.eckstein 1.2 in the response</li>
533 <li>CIM server returns 'access denied'</li>
534 </ul>
535 </li>
536 </ul>
537 </li>
538 </ol>
539 <h2><font color="#000000">Platform Considerations</font></h2>
540 <p><font color="#000000
|
541 kumpf 1.3 ">The coding guidelines may not help, but will not hurt implementations where
542 Pegasus and its providers are not run at elevated privilege. Examples of this
543 include environments with only one user or where Pegasus itself is executed
|
544 denise.eckstein 1.2 as the requesting user.</font></p>
545 <hr>
|
546 kumpf 1.3 <p><i><font size="2">Copyright (c) 2005 EMC Corporation; Hewlett-Packard Development
|
547 denise.eckstein 1.2 Company, L.P.; IBM Corp.; The Open Group; VERITAS Software Corporation</font><br>
548 <br>
|
549 kumpf 1.3 <font size="1">Permission is hereby granted, free of charge, to any person obtaining
550 a copy of this software and associated documentation files (the "Software"),
551 to deal in the Software without restriction, including without limitation the
552 rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
553 sell copies of the Software, and to permit persons to whom the Software is furnished
|
554 denise.eckstein 1.2 to do so, subject to the following conditions:</font><br>
555 <font size="2"><br>
|
556 kumpf 1.3 </font> <font size="1">THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE
557 SHALL BE INCLUDED IN ALL COPIES OR SUBSTANTIAL PORTIONS OF THE SOFTWARE. THE
558 SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
559 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
560 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
561 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
562 WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR
|
563 denise.eckstein 1.2 IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</font></i></p>
564 <hr>
565 </body>
|
566 kumpf 1.3 </html>
|
Return to
SecurityGuidelinesForDevelopers.html
CVS log
Up to [Pegasus] / pegasus / doc