[Openvas-commits] r3443 - trunk/doc/website

scm-commit@wald.intevation.org scm-commit at wald.intevation.org
Wed May 20 15:03:11 CEST 2009

Author: chandra
Date: 2009-05-20 15:03:10 +0200 (Wed, 20 May 2009)
New Revision: 3443

Extended the design and implementation approaches

Modified: trunk/doc/website/openvas-cr-25.htm4
--- trunk/doc/website/openvas-cr-25.htm4	2009-05-20 12:55:30 UTC (rev 3442)
+++ trunk/doc/website/openvas-cr-25.htm4	2009-05-20 13:03:10 UTC (rev 3443)
@@ -68,32 +68,26 @@
 This change request proposes to incorporate support for WMI into
-OpenVAS-libnasl through interacting with wmi-client daemon. Optionally,
-linking to an external library.
+OpenVAS-libnasl through interacting with wmi-client library.
 This would,
 - Provide support to scan Windows 2003 (in its default configuration),
   Windows Vista and Windows 2008.
+- Security policy changes to configure Windows system for local security
+  checks is not required. Policies such as SMB signing, encryption, NTLM
+  authentication levels are to be disabled currently.
 - Ease the writing of Windows based NVT's through simplified calls and
   newly added functions.
 - Number of new functions to interact with Windows based systems.
+- This introduces to a further dependency, wmi-client library. It might
+  be necessary to run this low privileges.
-Main disadvantage is the introduction to a further dependency, wmi-client.
-It might especially be necessary to build a daemon as wrapper around wmi-client
-in order to gain privilege separation. This of course make the setup
-of OpenVAS serverside more complicated.
 <h3>Design and Implementation</h3>
 There were two approaches proposed initially,
@@ -128,14 +122,17 @@
 <h4>Implementation Approach</h4>
-There is a wmi-client package available for several GNU/Linux distributions available which
-depends on SAMBA for DCOM support. The wmi-client can be either built as an
-.so or as a dameon which serves WMI client requests. wmi-client daemon would
-act as a proxy to OpenVAS serving WMI requests.
+There is a wmi-client package available for several GNU/Linux distributions
+available which depends on SAMBA for DCOM support. The wmi-client can be
+either built as .so. wmi-client daemon would act as a proxy to OpenVAS serving
+WMI requests. The following interfaces would be implemented,
+<h4>1. WQL queries</h4>
-The WQL queries will be embedded in NASL library (inc) files so that NASL
+WMI allows to query Windows system information through SQL like queries called
+WQL. An example WQL query is, "Select Caption from Win32_Process".
+These WQL queries will be embedded in NASL library (inc) files so that NASL
 developers call these functions instead of having to build WQL queries for
 each specific task. Also, for backward compatiability, it is suggested to
 have both smb_nt.inc approach and the WMI client approach to work seamlessly.
@@ -143,6 +140,20 @@
 backward comptiability issues.
+<h4>2. WMI RSOP (Resultant Set Policies) Implementation</h4>
+Windows system policies can be accessed through Win32 RSOP classes. WMI RSOP
+provider allows to have access to all the policy items through this provider.
+WMI queries in the form of WQL can be sent to this provider.
+<h4>3. WMI Registry provider </h4>
+To access the Windows System Registry, we need to make use of StdRegProv provider.
+Through WMI, it is possible to interact with this provider to access Windows
 <h4>Example Code </h4>
 Functions to list all the Windows Process and Service
@@ -202,35 +213,81 @@
 Phase I:
-- Create wmi-client daemon
-- openvas-libasl interaction with wmi-client
+a. Create wmi-client library <br>
+b. openvas-libasl interaction with wmi-client<br>
    - WQL query execution
-   - WMI remote command execution
 Phase II:
-NASL Library functions based on generic WQL queries
+a. WMI Client enhancement for RSOP <br>
+b. NASL Library functions based on generic WQL queries <br>
 - Registry
 - File system
 - Services
 - Process
 - System
+- Policy
+- User accounts
 Phase III:
-Backward compatibility:
+a. WMI Client enhancements for Windows Registry and File Effective Rights. The
+following functions will be implemented,
+- wmi_connect_reg
+- wmi_close
+- CheckAccess
+- EnumKey
+- EnumValues
+- GetBinaryValue
+- GetDWORDValue
+- GetExpandedStringValue
+- GetMultiStringValue
+- GetQWORDValue
+- GetSecurityDescriptor
+- GetStringValue
+- CreateKey
+- DeleteKey
+- DeleteValue
+- GetFileEffectiveRights
+Phase IV:
 - Wrapper NASL inc's to support earlier methods (smb_nt.inc) and new WMI methods
+Backward compatibility:
+With the introduction of WMI client interface, <br>
+1. All old Windows Plugins will continue to work with smb_nt.inc
+approach which require policy changes etc at each Windows box, to not 
+have signing/encryption enabled, to not have NTLM authentication etc.,
+2. All new Plugins will start using WMI, it'll make it mandatory to
+have WMI support with OpenVAS, otherwise Windows Plugins will not
+work. People using the older version of OpenVAS will not be able to
+run newer Plugins that use WMI.
+To handle the above issue, we can introduce a NASL inc layer that'll call
+either method (smb_nt.inc or WMI) according to the availability of WMI client
+library. If client library is available, it'll invoke the corresponding
+function or else it'll try the old function.
-Phase IV:
+Phase V:
 - Update OpenVAS compendium documenting all the newly added functions.
@@ -250,4 +307,8 @@
      2009-01-16 Jan-Oliver Wagner &lt;jan-oliver.wagner at intevation.de&gt;:<br>
      Some types, rephrasing and extending some arguments here and there.
+     2009-05-20 Chandrashekhar B &lt;bchandra at secpod.com&gt;:<br>
+     Extended the design and implementation approaches.

More information about the Openvas-commits mailing list