version 1.1, 2005/07/12 02:12:51
|
version 1.4, 2008/12/18 16:41:52
|
|
|
<html> | <html> |
|
|
<head> | <head> |
<meta http-equiv="Content-Language" content="en-us"> | <meta http-equiv="Content-Language" content="en-us"> |
<meta name="GENERATOR" content="Microsoft FrontPage 6.0"> |
|
<meta name="ProgId" content="FrontPage.Editor.Document"> |
|
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> | <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> |
<title>PEP</title> | <title>PEP</title> |
<link rel="stylesheet" href="http://www.opengroup.org/stylesheets/info1+margins.css"> | <link rel="stylesheet" href="http://www.opengroup.org/stylesheets/info1+margins.css"> |
<style> |
<style><!-- |
<!-- |
|
span.MsoCommentReference |
|
{} |
|
span.MsoFootnoteReference |
|
{vertical-align:super} |
|
--> | --> |
</style> | </style> |
</head> | </head> |
|
<body bgcolor="#FFFFFF"> |
<body> |
<h1> <font color="#000000">Pegasus Security Implementation Guidelines</font></h1> |
|
|
<h1> Pegasus Security Implementation Guidelines</h1> |
|
|
|
<hr> | <hr> |
|
|
<h2><font color="#000000">Problem Statement</font></h2> | <h2><font color="#000000">Problem Statement</font></h2> |
<p><font color="#000000">Open Pegasus has a challenging role. It provides a portal | <p><font color="#000000">Open Pegasus has a challenging role. It provides a portal |
for users and programs to access a wide variety of information on a system. | for users and programs to access a wide variety of information on a system. |
|
|
decide to run at elevated privilege (defined as when the execution context has | decide to run at elevated privilege (defined as when the execution context has |
more permissions/abilities than the authorized users... hard to avoid when the | more permissions/abilities than the authorized users... hard to avoid when the |
execution is not <em>as</em> the authorized user).</font></p> | execution is not <em>as</em> the authorized user).</font></p> |
<p> </p> |
<p><font color="#008000">Pre-2.5 implementations of OpenPegasus do not change |
|
the user-context (effective-user) of the provider from that of the CIMOM. Thus, |
|
when Pegasus is used on the majority of platforms (that don't provide intra-thread |
|
protections and/or work in a multi-user environment) a provider can, through |
|
mistake or intent, easily affect the security of the CIMOM and other providers. |
|
</font></p> |
<h2><font color="#000000">Requirements, Constraints or Assumptions</font></h2> | <h2><font color="#000000">Requirements, Constraints or Assumptions</font></h2> |
<p>Most of the risk of failing to follow the guidelines below are only present | <p>Most of the risk of failing to follow the guidelines below are only present |
when code is not run as the authenticated user (whether that code be in the | when code is not run as the authenticated user (whether that code be in the |
provider or the client) or in deployments for which the concept of authentication | provider or the client) or in deployments for which the concept of authentication |
isn't used (i.e.: SNMP-public info). Even for more limited deployments, many | isn't used (i.e.: SNMP-public info). Even for more limited deployments, many |
of the problems below can still cause potential crashes/denial of service conditions.</p> | of the problems below can still cause potential crashes/denial of service conditions.</p> |
|
|
<h2><font color="#000000">Definitions:</font></h2> | <h2><font color="#000000">Definitions:</font></h2> |
<p>Elevated code: a difference between the actions that |
<p>Elevated code: a difference between the actions that the logged in user is |
the logged in user is authorized to perform, and the execution context of the |
authorized to perform, and the execution context of the running program. |
running program. This "trust delta" must then be managed by the code to |
This "trust delta" must then be managed by the code to ensure that |
ensure that the user doesn't perform more actions than they are authorized |
the user doesn't perform more actions than they are authorized either directly |
either directly or through side-effect. For example, a process run as the |
or through side-effect. For example, a process run as the UID of the authenticated |
UID of the authenticated user is thus said to be "non-elevated." A process |
user is thus said to be "non-elevated." A process running as |
running as administrator on behalf of a "non-administrator" user, would be |
administrator on behalf of a "non-administrator" user, would be called |
called elevated.</p> |
elevated.</p> |
<p>Privilege: The collection of actions |
<p>Privilege: The collection of actions a process or user is not prevented from |
a process or user is not prevented from doing. An "administrator"/root |
doing. An "administrator"/root user is said to be full privilege |
user is said to be full privilege with respect to a system since that execution |
with respect to a system since that execution context does not prevent any action |
context does not prevent any action on the system.</p> |
on the system.</p> |
<p>Trust: The degree to which an actor |
<p>Trust: The degree to which an actor that is interacting with the component |
that is interacting with the component under consideration is believed to |
under consideration is believed to behave non-maliciously. For example, |
behave non-maliciously. For example, an arbitrary user on the Internet has |
an arbitrary user on the Internet has no 'trust," a junior operator or |
no 'trust," a junior operator or administration is trusted to no attempt |
administration is trusted to no attempt malicious activity, but may accidentally |
malicious activity, but may accidentally attempt damaging actions. |
attempt damaging actions. Root/Administrator code is trusted to behave |
Root/Administrator code is trusted to behave correctly.</p> |
correctly.</p> |
<p>Security Testing: Non-functional |
<p>Security Testing: Non-functional testing that centers around behavior in the |
testing that centers around behavior in the presence of malicious use. |
presence of malicious use. Examples includes testing for crashes or security |
Examples includes testing for crashes or security side-effects in the presence |
side-effects in the presence of overly long inputs, special character inputs, |
of overly long inputs, special character inputs, high-system load, and network |
high-system load, and network storm environments.</p> |
storm environments.</p> |
<p>Security Side Effect: Applications often, in accomplishing their goals, perform |
<p>Security Side Effect: Applications |
actions beyond those visible to the user. Examples include writing temporary |
often, in accomplishing their goals, perform actions beyond those visible to the |
files, or clearing or requesting memory. Since this behavior is not specified |
user. Examples include writing temporary files, or clearing or requesting |
in the functional requirements, it is often not tested. This "side |
memory. Since this behavior is not specified in the functional |
effect" behavior is often the behavior that a malicious user attempts to |
requirements, it is often not tested. This "side effect" behavior is often |
leverage when trying to gain privilege. Examples include exploiting race |
the behavior that a malicious user attempts to leverage when trying to gain |
conditions where a temporary file is momentarily world writeable, before it |
privilege. Examples include exploiting race conditions where a temporary |
is chmod-ed. This window is an opportunity for a malicious user to insert |
file is momentarily world writeable, before it is chmod-ed. This window is |
data that can change the behavior of the application.</p> |
an opportunity for a malicious user to insert data that can change the behavior |
|
of the application.</p> |
|
<h2><font color="#000000">References:</font></h2> | <h2><font color="#000000">References:</font></h2> |
<p>Architecture: |
<p>Architecture: <a href="http://www.opengroup.org/security/secarch.htm"> http://www.opengroup.org/security/secarch.htm</a></p> |
<a href="http://www.opengroup.org/security/secarch.htm"> |
<p>Books and References (not endorsed by Opengroup or partners): </p> |
http://www.opengroup.org/security/secarch.htm</a></p> |
|
<p>Books and References (not endorsed by |
|
Opengroup or partners): </p> |
|
<ul> | <ul> |
<li><a href="http://www.oreilly.com/catalog/securecdng/"> |
<li><a href="http://www.oreilly.com/catalog/securecdng/"> http://www.oreilly.com/catalog/securecdng/</a></li> |
http://www.oreilly.com/catalog/securecdng/</a></li> |
<li><a href="http://www.oreilly.com/catalog/puis3/"> http://www.oreilly.com/catalog/puis3/</a></li> |
<li><a href="http://www.oreilly.com/catalog/puis3/"> |
<li><a href="http://www.securityfocus.com/infocus/1596"> http://www.securityfocus.com/infocus/1596</a> |
http://www.oreilly.com/catalog/puis3/</a></li> |
</li> |
<li><a href="http://www.securityfocus.com/infocus/1596"> |
|
http://www.securityfocus.com/infocus/1596</a> </li> |
|
</ul> | </ul> |
<p> </p> |
|
<p> </p> |
|
<h2><font color="#000000">Proposed Solution </font></h2> | <h2><font color="#000000">Proposed Solution </font></h2> |
<h3>General Implementation Guidelines: |
<h3><font color="#000000">General Implementation Guidelines: </font></h3> |
</h3> |
<h4><font color="#000000">Code that doesn't adhere to the following guidelines |
<h4>Code that doesn't adhere to the following guidelines in elevated code should |
in elevated code should be considered a bug, including providers not running |
be considered a bug, including providers not running as-requestor. it is a best-practice |
as-requestor. it is a best-practice to follow the following guidelines for all |
to follow the following guidelines for all code. </h4> |
code. </font></h4> |
<p> </p> |
|
<ol> | <ol> |
<li> <u>Avoid buffer overflow vulnerabilities</u> in your code (hackers use | <li> <u>Avoid buffer overflow vulnerabilities</u> in your code (hackers use |
to insert arbitrary code) <br> | to insert arbitrary code) <br> |
|
|
strcat, gets, and strlcat.</li> | strcat, gets, and strlcat.</li> |
<ul> | <ul> |
<li> References:<br> | <li> References:<br> |
• 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> |
<ul> |
|
<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> |
<br> | <br> |
• Heap Overflows: <a href="http://www.phrack.org/phrack/57/p57-0x08%20">http://www.phrack.org/phrack/57/p57-0x08</a> |
<li> Heap Overflows: <a href="http://www.phrack.org/phrack/57/p57-0x08%20">http://www.phrack.org/phrack/57/p57-0x08</a> |
<br> | <br> |
|
</ul> |
</li> | </li> |
</ul> | </ul> |
<li> <u>Avoid format string vulnerabilities</u> in your code (hackers use to | <li> <u>Avoid format string vulnerabilities</u> in your code (hackers use to |
|
|
or exceptions gracefully.</li> | or exceptions gracefully.</li> |
<li>Keep your code simple: simple code decreases the risk of defects; complex | <li>Keep your code simple: simple code decreases the risk of defects; complex |
code increases the risk of defects.</li> | code increases the risk of defects.</li> |
<li> Don’t use uninitialized variables.</li> |
<li> Don't use uninitialized variables.</li> |
<li> Use symbolic constants (such as #define) to minimize typos and improve | <li> Use symbolic constants (such as #define) to minimize typos and improve |
code maintainability.</li> | code maintainability.</li> |
<li> Use temporary files with care. Do not create temporary directories | <li> Use temporary files with care. Do not create temporary directories |
|
|
<p>Correct: if 0 <= year <= 3000 then (accept input and process)</p> | <p>Correct: if 0 <= year <= 3000 then (accept input and process)</p> |
<p>Unsafe: if year <= 3000 then (accept input and process)</p> | <p>Unsafe: if year <= 3000 then (accept input and process)</p> |
<p>The vulnerability of the unsafe example is that if someone were to | <p>The vulnerability of the unsafe example is that if someone were to |
return a value of –32769, then they could intentionally stop or corrupt |
return a value of -32769, then they could intentionally stop or corrupt |
a procedure. If the language which you are using does not enforce | a procedure. If the language which you are using does not enforce |
strong types, then a type check should also be performed before accepting | strong types, then a type check should also be performed before accepting |
the input.</p> | the input.</p> |
|
|
<li> <u>Use the principles of least and necessary privilege</u>.<br> | <li> <u>Use the principles of least and necessary privilege</u>.<br> |
Only grant the minimum set of privileges required to perform an operation, | Only grant the minimum set of privileges required to perform an operation, |
and grant these privileges for the minimum required amount of time. For example, | and grant these privileges for the minimum required amount of time. For example, |
if a provider needs to modify both mail queues and print spools, don’t run |
if a provider needs to modify both mail queues and print spools, don't run |
the application as root; instead, use /etc/logingroup or other facilities | the application as root; instead, use /etc/logingroup or other facilities |
to give the application the privileges which it needs, but not more privileges | to give the application the privileges which it needs, but not more privileges |
than it needs. <br> | than it needs. <br> |
|
|
Additional details can be found at: <a href="http://www.joeyoder.com/papers/patterns/Security/appsec.pdf"> | Additional details can be found at: <a href="http://www.joeyoder.com/papers/patterns/Security/appsec.pdf"> |
Architectural Patterns for Enabling Application Security</a> <font size="-4">(http://www.joeyoder.com/papers/patterns/Security/appsec.pdf)</font></li> | Architectural Patterns for Enabling Application Security</a> <font size="-4">(http://www.joeyoder.com/papers/patterns/Security/appsec.pdf)</font></li> |
<li> <u>Test for security </u>(use both positive and negative tests)<br> | <li> <u>Test for security </u>(use both positive and negative tests)<br> |
“Positive tests” verify that the functionality of the product works as specified. |
"Positive tests"verify that the functionality of the product works as specified. |
“Negative tests” attempt to subvert the security of the system, and are often |
"Negative tests"attempt to subvert the security of the system, and are often |
overlooked when testing software. Spend some time thinking like a hacker and | overlooked when testing software. Spend some time thinking like a hacker and |
trying to break your system. Always test boundary conditions or corner cases | trying to break your system. Always test boundary conditions or corner cases |
for values of data, size of data, and type of data. Many common bugs are related | for values of data, size of data, and type of data. Many common bugs are related |
to this. Sometimes this type of bug may result in wrong information being | to this. Sometimes this type of bug may result in wrong information being |
retrieved from the database instead of failing gracefully. Attempt to exploit | retrieved from the database instead of failing gracefully. Attempt to exploit |
the system with buffer overflow and format string attacks.</li> | the system with buffer overflow and format string attacks.</li> |
<li> <u>Don’t bundle private copies of security code</u><br> |
<li> <u>Don't bundle private copies of security code</u><br> |
Security code (especially highly scrutinized open-source code) is likely to | Security code (especially highly scrutinized open-source code) is likely to |
have security bulletins issued against it. When such security bulletins are | have security bulletins issued against it. When such security bulletins are |
inevitably issued against code you depend on, you don’t want to have to issue |
inevitably issued against code you depend on, you don't want to have to issue |
a bulletin against your product also. If you put a dependency in your code | a bulletin against your product also. If you put a dependency in your code |
to a standard distribution of a component which you need (for example OpenSSL), | to a standard distribution of a component which you need (for example OpenSSL), |
rather than embedding a private copy, then whenever a security bulletin is | rather than embedding a private copy, then whenever a security bulletin is |
issued against it, you won’t have to reissue the bulletin after repacking |
issued against it, you won't have to reissue the bulletin after repacking |
the fix for your private copy. <br> | the fix for your private copy. <br> |
</li> | </li> |
</ol> | </ol> |
<h4>General Coding Best-Practices:</h4> |
<h4><font color="#000000">General Coding Best-Practices:</font></h4> |
<ol> | <ol> |
<li> <u>Avoid implementing security functionality</u>: Making security claims | <li> <u>Avoid implementing security functionality</u>: Making security claims |
in your documentation (beyond the implied security claims of authentication | in your documentation (beyond the implied security claims of authentication |
|
|
<li><u>Duplicating authorization code</u>: Related to risk #1, every provider | <li><u>Duplicating authorization code</u>: Related to risk #1, every provider |
has the risk of authorization related defects because the authorization done | has the risk of authorization related defects because the authorization done |
in each provider is a duplication of the kernel authorization code. However, | in each provider is a duplication of the kernel authorization code. However, |
you can still decrease your risk by using common API’s. For example, many |
you can still decrease your risk by using common API's. For example, many |
providers will need a way to tell if the authenticated user should have access | providers will need a way to tell if the authenticated user should have access |
to a given file. The code which does this needs to check the user id, group | to a given file. The code which does this needs to check the user id, group |
ids of the file in question and all of its parent directories. Any defect | ids of the file in question and all of its parent directories. Any defect |
|
|
<ol> | <ol> |
<li>using the connectLocal() API uses the UID of the running process to | <li>using the connectLocal() API uses the UID of the running process to |
do authentication. Thus, the provider initiating the request must ensure | do authentication. Thus, the provider initiating the request must ensure |
authorization of the other provider’s data before making the request. |
authorization of the other provider's data before making the request. |
(This is another example of Risk 2, multiple copies of authorization code) | (This is another example of Risk 2, multiple copies of authorization code) |
One feasible way to do this is to check that the user is a privileged | One feasible way to do this is to check that the user is a privileged |
user before calling the other provider (in which case the UID matches | user before calling the other provider (in which case the UID matches |
|
|
</ol> | </ol> |
</li> | </li> |
</ol> | </ol> |
<h3> Provider Implementation Guidelines |
<h3> <font color="#000000">Provider Implementation Guidelines </font></h3> |
</h3> |
<h4> <font color="#000000">Code that doesn't following the following guidelines |
<h4> Code that doesn't following the |
in providers running at elevated-privilege should be considered a bug.<br> |
following guidelines in providers running at elevated-privilege should be |
|
considered a bug.<br> |
|
Code in providers running as-requestor can consider the following as general | Code in providers running as-requestor can consider the following as general |
best practice.</h4> |
best practice.</font></h4> |
<ol> | <ol> |
<li> <u>Check the username/uid and execute every method as if it was running | <li> <u>Check the username/uid and execute every method as if it was running |
as that user</u> (i.e. had the OS kernel or |
as that user</u> (i.e. had the OS kernel or authorization service done the |
authorization service done the authorization).<br> |
authorization).<br> |
By checking each operation they perform, and ensuring those operations, when | By checking each operation they perform, and ensuring those operations, when |
performed on behalf of a non-privileged user, do not have security side-effects. | performed on behalf of a non-privileged user, do not have security side-effects. |
Any discrepancy between OS authorizations done by the kernel and that done | Any discrepancy between OS authorizations done by the kernel and that done |
|
|
the Provider must throw CIMAccessDeniedException.</li> | the Provider must throw CIMAccessDeniedException.</li> |
<li> <u>Keep your design/provider simple.</u> <br> | <li> <u>Keep your design/provider simple.</u> <br> |
While this is difficult to quantify, it is important to minimize the amount | While this is difficult to quantify, it is important to minimize the amount |
of code running as a privileged user. As a general guideline, if you have significant lines |
of code running as a privileged user. As a general guideline, if you have |
of code running with elevated privilege, the likelihood of a security |
significant lines of code running with elevated privilege, the likelihood |
defect is high. Remember that defects in elevated privilege code is a potential |
of a security defect is high. Remember that defects in elevated privilege |
security defect, so all of this code must be straightforward and easy to review |
code is a potential security defect, so all of this code must be straightforward |
based on the principles mentioned in the General Coding principles above. |
and easy to review based on the principles mentioned in the General Coding |
The likelihood of a defect not being found is proportional to the amount and |
principles above. The likelihood of a defect not being found is proportional |
complexity of the code. </li> |
to the amount and complexity of the code. </li> |
<li><u>Provider must not use any calls such as setuid or setting environment | <li><u>Provider must not use any calls such as setuid or setting environment |
variables (i.e. PATH) that would alter the state of the process running the | variables (i.e. PATH) that would alter the state of the process running the |
CIM Server.</u> <br> | CIM Server.</u> <br> |
|
|
<li><u>Do not allow group or world-write access </u>to your shared library, | <li><u>Do not allow group or world-write access </u>to your shared library, |
any other executable code, configuration files, or any parent directory of | any other executable code, configuration files, or any parent directory of |
any of the above. <br> | any of the above. <br> |
Although only a privileged user |
Although only a privileged user ought to be able to create the symbolic links |
ought to be able to create the symbolic links |
or shortcuts to the provider shared library in the designated WBEM provider |
or shortcuts to the provider |
library directory, the actual provider shared library can be placed in any |
shared library in the designated WBEM provider library directory, the actual |
directory. A provider must ensure that their shared libraries are protected |
provider shared library can be placed in any directory. A provider must ensure |
in such a way that only a privileged user can modify or delete the shared |
that their shared libraries are protected in such a way that only a privileged |
library or the directory where the shared library is located.</li> |
user can modify or delete the shared library or the directory where the shared |
<li><u><font color="#008000">Don't bypass authentication</font></u><font color="#008000">: |
library is located.</li> |
To avoid damaging CIMOM and other-providers' security, providers should not |
|
bypass CIMOM authentication steps in communicating to other providers or the |
|
CIMOM (manipulating CIMOM-handle userid) and instead use CIMClient in accordance |
|
with "General-Client Best Practices" section. In cases where the |
|
Pegasus use-model does rely on platform-native inter-thread protections, a |
|
future protection algorithm may have to be implemented in OpenPegasus that |
|
ensures an unchanged state of the operation context. Note however that, In |
|
Pegasus 2.5, if a provider uses run-as-requestor, that will ensure the provider |
|
runs in the right user-context, and cleans up the interface to that provider |
|
to ensure it doesn't skip inter-provider authentication. </font><br> |
|
</li> |
</ol> | </ol> |
<h4><br> | <h4><br> |
Provider Best-Practices:</h4> |
<font color="#000000">Provider Best-Practices:</font></h4> |
<ol> | <ol> |
<li><u>Use "UserContext registration" setting, present in Open Pegasus | <li><u>Use "UserContext registration" setting, present in Open Pegasus |
2.5 and later</u>: <br> | 2.5 and later</u>: <br> |
In Pegasus 2.5 and after, you should strongly consider registering your provider | In Pegasus 2.5 and after, you should strongly consider registering your provider |
to run as requestor context, or if |
to run as requestor context, or if not available, use Windows "impersonation" |
not available, use Windows "impersonation" or fork a correct-user-running |
or fork a correct-user-running process. For providers in versions prior to |
process. For providers in versions prior to 2.5, you may |
2.5, you may want to consider implementing your own out of process provider, |
want to consider implementing your own out of process provider, to avoid the |
to avoid the risks of running at elevated privilege. For those that must run |
risks of running at elevated privilege. For those that must run privileged: |
privileged: </li> |
</li> |
|
<ul> | <ul> |
<li><u>Check that the authenticated username provided by |
<li><u>Check that the authenticated username provided by CIM matches the effective |
CIM matches the |
user id</u> of the running process. For Pegasus 2.4 and prior, this means |
effective user id</u> of the running process. |
that only the privileged user would be able to use your provider. The general |
For Pegasus 2.4 and |
property is that if you are not elevating privilege (running on behalf of |
prior, this means that only the privileged user would be able to use your provider. |
a different user), then the likelihood of a security defect is greatly decreased. |
The general property is that if you are not elevating privilege (running |
Making your code more general may mean less work in the future when non-privilege-elevated |
on behalf of a different user), then the likelihood of a security defect |
providers are able to run with the correct user-id. Even in the model |
is greatly decreased. Making your code more general may mean less work in |
where Pegasus is run under a non-privileged user, there is a delta in "trust" |
the future when non-privilege-elevated providers are able to run with the correct user-id. |
between the different users. This still represents some, though not |
Even in the model where Pegasus is |
as much, risk as deploying a run-as-administrator Pegasus. There is |
run under a non-privileged user, there is a delta in "trust" between the |
an opportunity to improve Pegasus to better support fully protecting this |
different users. This still represents some, though not as much, risk |
use model, though this is less urgent than protecting the higher risk associated |
as deploying a run-as-administrator Pegasus. There is an opportunity |
with an administrator running CIM server.</li> |
to improve Pegasus to better support fully protecting this use model, though |
<li><u>Recommend configuring the WBEM users group (ref: PEP 142)</u>: For |
this is less urgent than protecting the higher risk associated with an |
Pegasus versions prior to 2.5, and subsequent, customers can configure a |
administrator running CIM server.</li> |
specific group of users who has access to WBEM providers. This allows customers |
<li><u>Recommend configuring the WBEM users group |
to choose a tradeoff between security risk and ease-of-setup. Since every |
(ref: PEP 142)</u>: For Pegasus versions |
provider runs with elevated privilege, the risk of security defects is high. |
prior to 2.5, and subsequent, customers can configure a specific group of users who |
Thus, it is advised that customers configure this group of WBEM users to |
has access to WBEM providers. This allows customers to choose a tradeoff |
only allow access to users who are trusted not to be malicious. If you also |
between security risk and ease-of-setup. Since every provider runs with |
do not run by default, this information can be in your initial setup documentation |
elevated privilege, the risk of security defects is high. Thus, it is advised |
so that it gets to all of your customers. This can greatly decrease your |
that customers configure this group of WBEM users to only allow access to |
risk of having a security defect, because all malicious activities can be |
users who are trusted not to be malicious. If you also do not run by default, |
potentially ruled out.</li> |
this information can be in your initial setup documentation so that it gets |
|
to all of your customers. This can greatly decrease your risk of having |
|
a security defect, because all malicious activities can be potentially ruled |
|
out.</li> |
|
</ul> | </ul> |
<li><u>Providers should consider the tradeoff between default installation/registration | <li><u>Providers should consider the tradeoff between default installation/registration |
and optional</u>: An optional installation of a component (as part of | and optional</u>: An optional installation of a component (as part of |
|
|
who do not need the functionality you provide. There are many customers who | who do not need the functionality you provide. There are many customers who |
would prefer less patching/update cost and decreased security risk (risk is | would prefer less patching/update cost and decreased security risk (risk is |
added whenever there is a new interface) versus the functionality that your | added whenever there is a new interface) versus the functionality that your |
product provides. Although technically this doesn’t decrease the risk of having |
product provides. Although technically this doesn't decrease the risk of having |
a security defect, it can give you more options for interim workarounds until | a security defect, it can give you more options for interim workarounds until |
you can get a critical fix out, and fewer customers would be affected by any | you can get a critical fix out, and fewer customers would be affected by any |
given defect. Provider writers and bundlers should consider these benefits | given defect. Provider writers and bundlers should consider these benefits |
|
|
with access to the log. It is recommended that you use a common logging facility, | with access to the log. It is recommended that you use a common logging facility, |
such as syslog. Syslogd takes care of things like log rotation, etc. and the | such as syslog. Syslogd takes care of things like log rotation, etc. and the |
administrator already knows where to look for your logs.</li> | administrator already knows where to look for your logs.</li> |
<li><u>When making system changes, use |
<li><u>When making system changes, use platform security checks where possible |
platform security checks where possible vs. rewriting your own authorization |
vs. rewriting your own authorization code</u>: Duplicating authorization code |
code</u>: Duplicating |
at least doubles the work and is more error-prone.</li> |
authorization code at least doubles the work and is more error-prone.</li> |
|
</ol> | </ol> |
<h3> Client Implementation Guidelines:</h3> |
<h3> <font color="#000000">Client Implementation Guidelines:</font></h3> |
<p> Note: In general, these are the |
<p> Note: In general, these are the responsibility of the applications invoking |
responsibility of the applications invoking CIM client libraries to the extent |
CIM client libraries to the extent that the client libraries don't yet provide |
that the client libraries don't yet provide the direct support.</p> |
the direct support.</p> |
<h4> Client code that doesn't follow |
<h4> <font color="#000000">Client code that doesn't follow these guidelines should |
these guidelines should be considered a bug:</h4> |
be considered a bug:</font></h4> |
<ol> | <ol> |
<li><u>Use SSL as<a> follows in your remote production client. Though WBEM does | <li><u>Use SSL as<a> follows in your remote production client. Though WBEM does |
provide libraries to help, client behavior is the client's responsibility:</a></u></li> | provide libraries to help, client behavior is the client's responsibility:</a></u></li> |
<li><u>Protect the Keystore and Truststore for remote production clients</u>:<ul> |
<li><u>Protect the Keystore and Truststore for remote production clients</u>: |
<li>Use proper file and |
<ul> |
directory permissions to protect keystore and |
<li>Use proper file and directory permissions to protect keystore and truststore |
truststore files. </li> |
files. </li> |
<li>If your applications are importing the servers’ certificate to a |
<li>If your applications are importing the servers' certificate to a truststore, |
truststore, you must ensure that the user validates the certificates |
you must ensure that the user validates the certificates received before |
received before adding them to a truststore or keystore.</li> |
adding them to a truststore or keystore.</li> |
<li>Do not use less than 1024 bit keysize to create keystores.</li> | <li>Do not use less than 1024 bit keysize to create keystores.</li> |
<li>Keystores/truststores should not be readable or writeable by anyone | <li>Keystores/truststores should not be readable or writeable by anyone |
other than the user who owns them.</li> | other than the user who owns them.</li> |
</ul></li> |
</ul> |
<li><u>General programming standards</u><ul> |
</li> |
<li>Do not use world-writable files or directories (including /tmp and /var/tmp). |
<li><u>General programming standards</u> |
Make sure all credentials (passwords/certificates) are readable only by |
<ul> |
their owner.</li> |
<li>Do not use world-writeable files or directories (including /tmp and |
|
/var/tmp). Make sure all credentials (passwords/certificates) are |
|
readable only by their owner.</li> |
<li>Do not cache passwords unless directed to do so by the user. The | <li>Do not cache passwords unless directed to do so by the user. The |
user should be aware that their password is being stored permanently on | user should be aware that their password is being stored permanently on |
the client machine.</li> | the client machine.</li> |
<li>Do not pass passwords as an option on the command-line in |
<li>Do not pass passwords as an option on the command-line in non-windows |
non-windows clients. |
clients. Command-lines are visible to all users on the system in |
Command-lines are visible to all users on the system in |
|
some operating systems.</li> | some operating systems.</li> |
</ul></li> |
</ul> |
|
</li> |
</ol> | </ol> |
<h4>General client best-practices:</h4> |
<h4><font color="#000000">General client best-practices:</font></h4> |
<ol> | <ol> |
<li><u>Limit access to client data</u>: Each user of a WBEM client should have | <li><u>Limit access to client data</u>: Each user of a WBEM client should have |
his/her own WBEM client instance. The WBEM client process should run | his/her own WBEM client instance. The WBEM client process should run |
|
|
code scanners such as these tend to make a lot of recommendations, so | code scanners such as these tend to make a lot of recommendations, so |
plan on adequate time for manual analysis and focus on your input validation | plan on adequate time for manual analysis and focus on your input validation |
module.)</li> | module.)</li> |
<li>Do not use world-writable files or directories (including /tmp and /var/tmp). |
<li>Do not use world-writeable files or directories (including /tmp and |
Make sure all credentials (passwords/certificates) are readable only by |
/var/tmp). Make sure all credentials (passwords/certificates) are |
their owner.</li> |
readable only by their owner.</li> |
<li>Do not cache passwords unless directed to do so by the user. The | <li>Do not cache passwords unless directed to do so by the user. The |
user should be aware that their password is being stored permanently on | user should be aware that their password is being stored permanently on |
the client machine.</li> | the client machine.</li> |
|
|
<li>CIM server responds with an extremely large response</li> | <li>CIM server responds with an extremely large response</li> |
<li>CIM server or provider responds with invalid characters or garbage | <li>CIM server or provider responds with invalid characters or garbage |
in the response</li> | in the response</li> |
<li>CIM server returns ‘access denied’</li> |
<li>CIM server returns 'access denied'</li> |
</ul> | </ul> |
</li> | </li> |
</ul> | </ul> |
|
|
include environments with only one user or where Pegasus itself is executed | include environments with only one user or where Pegasus itself is executed |
as the requesting user.</font></p> | as the requesting user.</font></p> |
<hr> | <hr> |
<p><i><font size="2">Copyright (c) 2005 EMC Corporation; Hewlett-Packard Development |
<p>Licensed to The Open Group (TOG) under one or more contributor license |
Company, L.P.; IBM Corp.; The Open Group; VERITAS Software Corporation</font><br> |
agreements. Refer to the OpenPegasusNOTICE.txt file distributed with |
<br> |
this work for additional information regarding copyright ownership. |
<font size="1">Permission is hereby granted, free of charge, to any person |
Each contributor licenses this file to you under the OpenPegasus Open |
obtaining a copy of this software and associated documentation files (the |
Source License; you may not use this file except in compliance with the |
"Software"), to deal in the Software without restriction, including without |
License.</p> |
limitation the rights to use, copy, modify, merge, publish, distribute, |
<p>Permission is hereby granted, free of charge, to any person obtaining a |
sublicense, and/or sell copies of the Software, and to permit persons to whom |
copy of this software and associated documentation files (the "Software"), |
the Software is furnished to do so, subject to the following conditions:</font><br> |
to deal in the Software without restriction, including without limitation |
<font size="2"><br> |
the rights to use, copy, modify, merge, publish, distribute, sublicense, |
</font> |
and/or sell copies of the Software, and to permit persons to whom the |
<font size="1">THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE SHALL BE INCLUDED IN ALL |
Software is furnished to do so, subject to the following conditions:</p> |
COPIES OR SUBSTANTIAL PORTIONS OF THE SOFTWARE. THE SOFTWARE IS PROVIDED |
<p>The above copyright notice and this permission notice shall be included |
"AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT |
in all copies or substantial portions of the Software.</p> |
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE |
<p>THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS |
AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE |
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF |
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF |
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. |
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE |
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY |
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</font></i></p> |
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, |
|
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE |
|
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</p> |
<hr> | <hr> |
</body> | </body> |
|
|
</html> | </html> |