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