pegasus/doc/SecurityGuidelinesForDevelopers.html - diff

Return to SecurityGuidelinesForDevelopers.html CVS log

Up to [Pegasus] / pegasus / doc

Diff for /pegasus/doc/SecurityGuidelinesForDevelopers.html between version 1.1 and 1.2

version 1.1, 2005/07/12 02:12:51

version 1.2, 2005/08/11 07:46:07

Line 1

<html>

<head>

<style>

<style><!--

<!--

span.MsoCommentReference

{}

span.MsoFootnoteReference

{vertical-align:super}

-->

</style>

</head>

<body>

<h1> <font color="#000000">Pegasus Security Implementation Guidelines</font></h1>

<h1> Pegasus Security Implementation Guidelines</h1>

<hr>

<h2><font color="#000000">Problem Statement</font></h2>

<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.

Line 40

Line 28

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

execution is not <em>as</em> the authorized user).</font></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>

<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

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

of the problems below can still cause potential crashes/denial of service conditions.</p>

<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>

<p>Architecture:

<p>Architecture: <a href="http://www.opengroup.org/security/secarch.htm"> http://www.opengroup.org/security/secarch.htm</a></p>

<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>

<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.securityfocus.com/infocus/1596"> http://www.securityfocus.com/infocus/1596</a>

http://www.oreilly.com/catalog/puis3/</a></li>

</li>

http://www.securityfocus.com/infocus/1596</a> </li>

</ul>

<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>

<ol>

<li> <u>Avoid buffer overflow vulnerabilities</u> in your code (hackers use

to insert arbitrary code) <br>

Line 118

Line 100

strcat, gets, and strlcat.</li>

<ul>

<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>

� 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>

</ul>

</li>

</ul>

<li> <u>Avoid format string vulnerabilities</u> in your code (hackers use to

Line 150

Line 134

or exceptions gracefully.</li>

<li>Keep your code simple: simple code decreases the risk of defects; complex

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

code maintainability.</li>

<li> Use temporary files with care. Do not create temporary directories

Line 175

Line 159

<p>Correct: if 0 <= 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

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

strong types, then a type check should also be performed before accepting

the input.</p>

Line 186

Line 170

<li> <u>Use the principles of least and necessary privilege</u>.<br>

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,

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

to give the application the privileges which it needs, but not more privileges

than it needs. <br>

Line 216

Line 200

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>

<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

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

to this. Sometimes this type of bug may result in wrong information being

retrieved from the database instead of failing gracefully. Attempt to exploit

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

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

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

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>

</li>

</ol>

<h4>General Coding Best-Practices:</h4>

<h4><font color="#000000">General Coding Best-Practices:</font></h4>

<ol>

<li> <u>Avoid implementing security functionality</u>: Making security claims

in your documentation (beyond the implied security claims of authentication

Line 251

Line 235

<li><u>Duplicating authorization code</u>: Related to risk #1, every provider

has the risk of authorization related defects because the authorization done

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

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

Line 266

Line 250

<ol>

<li>using the connectLocal() API uses the UID of the running process to

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)

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

Line 279

Line 263

</ol>

</li>

</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

best practice.</h4>

best practice.</font></h4>

<ol>

<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

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

Line 298

Line 280

the Provider must throw CIMAccessDeniedException.</li>

<li> <u>Keep your design/provider simple.</u> <br>

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

variables (i.e. PATH) that would alter the state of the process running the

CIM Server.</u> <br>

Line 342

Line 324

<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 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>

Provider Best-Practices:</h4>

<font color="#000000">Provider Best-Practices:</font></h4>

<ol>

<li><u>Use "UserContext registration" setting, present in Open Pegasus

2.5 and later</u>: <br>

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>

<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>

<li><u>Providers should consider the tradeoff between default installation/registration

and optional</u>:  An optional installation of a component (as part of

Line 401

Line 388

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

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

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

Line 413

Line 400

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

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>

<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>

<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>

<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>Keystores/truststores should not be readable or writeable by anyone

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

user should be aware that their password is being stored permanently on

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>

</ul></li>

</ul>

</li>

</ol>

<h4>General client best-practices:</h4>

<h4><font color="#000000">General client best-practices:</font></h4>

<ol>

<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

Line 505

Line 493

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

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

user should be aware that their password is being stored permanently on

the client machine.</li>

Line 542

Line 530

<li>CIM server responds with an extremely large response</li>

<li>CIM server or provider responds with invalid characters or garbage

in the response</li>

<li>CIM server returns �access denied�</li>

<li>CIM server returns 'access denied'</li>

</ul>

</li>

</ul>

Line 558

Line 546

Company, L.P.; IBM Corp.; The Open Group; VERITAS Software Corporation</font><br>

<br>

<font size="1">Permission is hereby granted, free of charge, to any person

<font size="1">Permission is hereby granted, free of charge, to any person obtaining

obtaining a copy  of this software and associated documentation files (the

a copy  of this software and associated documentation files (the "Software"),

"Software"), to deal in the Software without restriction, including without

to deal in the Software without restriction, including without limitation the

limitation the rights to use, copy, modify, merge, publish, distribute,

rights to use, copy, modify, merge, publish, distribute, sublicense, and/or

sublicense, and/or sell copies of the Software, and to permit persons to whom

sell copies of the Software, and to permit persons to whom the Software is furnished

the Software is furnished to do so, subject to the following conditions:</font><br>

to do so, subject to the following conditions:</font><br>

</font>

</font> <font size="1">THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE

<font size="1">THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE SHALL BE INCLUDED IN ALL

SHALL BE INCLUDED IN ALL COPIES OR SUBSTANTIAL PORTIONS OF THE SOFTWARE. THE

COPIES OR SUBSTANTIAL PORTIONS OF THE SOFTWARE. THE SOFTWARE IS PROVIDED 

SOFTWARE IS PROVIDED  "AS IS", WITHOUT WARRANTY OF ANY KIND,

"AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT

EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,

LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE

FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE

AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE

AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,

LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF

WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR

CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE

IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</font></i></p>

SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</font></i></p>

<hr>

</body>

</html>

Legend:

Removed from v.1.1
changed lines
	Added in v.1.2

No CVS admin address has been configured