Clarification of IOS schema line_object and global_object elements

classic Classic list List threaded Threaded
13 messages Options
mvg
Reply | Threaded
Open this post in threaded view
|

Clarification of IOS schema line_object and global_object elements

mvg
Hi All,

I'm trying to understand the OVAL schema for Cisco IOS and I was
hoping that someone could clarify the intended operation of the
line_object and global_object elements.

Should line_object generate one line_item containing all lines output
by the corresponding show_subcommand or should it generate a separate
line_item each line returned by the command?

If the first, should beginning and end of line anchors match at
newlines within the string?  Examples in the OVAL repository seem to
assume that one can match a line like "ip http secure-server" using
"^\s*ip http secure-server" instead of "\n\s*ip http secure-server".

If the second, how should a rule writer determine context?  For
instance, if I were checking that only SSH transports were enabled on
a given terminal line I'd need to check transport directives that are
children of a line command as in:
line vty 0 4
 access-class 23 in
 privilege level 15
 transport input ssh
 transport output ssh

This can be done by checking "transport" commands following a "line"
command without any other intervening "line" commands.  However, doing
so requires the line_item to contain multiple lines of output (as
opposed to a separate item for each line).

I have similar questions with regard to global_object.  Should
global_object create a separate global_item for each "particular line"
in the configuration, or a single global_item with all lines from the
configuration?

Given global_object's name, should global_object only return item(s)
for configuration commands in "global configuration mode" (top level)
[1] or should it also return item(s) for commands that are in lower
levels of the configuration hierarchy (such as interface or line
configuration mode)?

As there are precious few IOS examples on the web and there is not yet
a reference implementation, I appreciate any feedback you might have.

Thanks,
Matt Van Gundy

[1] http://www.cisco.com/en/US/docs/ios/preface/usingios.html

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Clarification of IOS schema line_object and global_object elements

joval
Hi Matthew,

I agree that the specification is ambiguous.  Sometimes when faced with ambiguity in OVAL I'll search the discussion group messages, and occasionally find an old thread on the topic that clarifies things.  I don't recall turning anything up on this topic, though.

Currently, jOVAL implements the line_object by putting the entire output of the command into the config_line of a single line_item element, as there is nothing (like a line_number or instance element) that could be used to reassemble the output.  We don't yet implement the global_object.

We're actually planning to complete our implementation of the entire IOS schema over the next few weeks, so I'd be very interested in hearing any thoughts or requirements you have about the individual tests.  Please feel free to contact me directly.

Best regards,
--David Solin

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download



On 1/10/2012 3:27 PM, Matthew Van Gundy wrote:
Hi All,

I'm trying to understand the OVAL schema for Cisco IOS and I was
hoping that someone could clarify the intended operation of the
line_object and global_object elements.

Should line_object generate one line_item containing all lines output
by the corresponding show_subcommand or should it generate a separate
line_item each line returned by the command?

If the first, should beginning and end of line anchors match at
newlines within the string?  Examples in the OVAL repository seem to
assume that one can match a line like "ip http secure-server" using
"^\s*ip http secure-server" instead of "\n\s*ip http secure-server".

If the second, how should a rule writer determine context?  For
instance, if I were checking that only SSH transports were enabled on
a given terminal line I'd need to check transport directives that are
children of a line command as in:
line vty 0 4
 access-class 23 in
 privilege level 15
 transport input ssh
 transport output ssh

This can be done by checking "transport" commands following a "line"
command without any other intervening "line" commands.  However, doing
so requires the line_item to contain multiple lines of output (as
opposed to a separate item for each line).

I have similar questions with regard to global_object.  Should
global_object create a separate global_item for each "particular line"
in the configuration, or a single global_item with all lines from the
configuration?

Given global_object's name, should global_object only return item(s)
for configuration commands in "global configuration mode" (top level)
[1] or should it also return item(s) for commands that are in lower
levels of the configuration hierarchy (such as interface or line
configuration mode)?

As there are precious few IOS examples on the web and there is not yet
a reference implementation, I appreciate any feedback you might have.

Thanks,
Matt Van Gundy

[1] http://www.cisco.com/en/US/docs/ios/preface/usingios.html

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].


To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|

Re: Clarification of IOS schema line_object and global_object elements

Igor Prata

Hello Matthew.

 

As jOVAL, modSIC implements the line_object catching the entire output of a command. Our OVAL Definitions test works with pattern match on those output.

In our cases, we developed probes for line_object and Version55_object in Cisco iOS schema.

 

 

 

 

Best Regards.

 

 

Igor Prata

modSIC Team - www.modsic.org

Modulo Solutions for GRC - http://www.modulo.com

 

 

 

From: David Solin [mailto:[hidden email]]
Sent: terça-feira, 10 de janeiro de 2012 21:40
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Clarification of IOS schema line_object and global_object elements

 

Hi Matthew,

I agree that the specification is ambiguous.  Sometimes when faced with ambiguity in OVAL I'll search the discussion group messages, and occasionally find an old thread on the topic that clarifies things.  I don't recall turning anything up on this topic, though.

Currently, jOVAL implements the line_object by putting the entire output of the command into the config_line of a single line_item element, as there is nothing (like a line_number or instance element) that could be used to reassemble the output.  We don't yet implement the global_object.

We're actually planning to complete our implementation of the entire IOS schema over the next few weeks, so I'd be very interested in hearing any thoughts or requirements you have about the individual tests.  Please feel free to contact me directly.

Best regards,
--David Solin

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download



On 1/10/2012 3:27 PM, Matthew Van Gundy wrote:

Hi All,
 
I'm trying to understand the OVAL schema for Cisco IOS and I was
hoping that someone could clarify the intended operation of the
line_object and global_object elements.
 
Should line_object generate one line_item containing all lines output
by the corresponding show_subcommand or should it generate a separate
line_item each line returned by the command?
 
If the first, should beginning and end of line anchors match at
newlines within the string?  Examples in the OVAL repository seem to
assume that one can match a line like "ip http secure-server" using
"^\s*ip http secure-server" instead of "\n\s*ip http secure-server".
 
If the second, how should a rule writer determine context?  For
instance, if I were checking that only SSH transports were enabled on
a given terminal line I'd need to check transport directives that are
children of a line command as in:
line vty 0 4
 access-class 23 in
 privilege level 15
 transport input ssh
 transport output ssh
 
This can be done by checking "transport" commands following a "line"
command without any other intervening "line" commands.  However, doing
so requires the line_item to contain multiple lines of output (as
opposed to a separate item for each line).
 
I have similar questions with regard to global_object.  Should
global_object create a separate global_item for each "particular line"
in the configuration, or a single global_item with all lines from the
configuration?
 
Given global_object's name, should global_object only return item(s)
for configuration commands in "global configuration mode" (top level)
[1] or should it also return item(s) for commands that are in lower
levels of the configuration hierarchy (such as interface or line
configuration mode)?
 
As there are precious few IOS examples on the web and there is not yet
a reference implementation, I appreciate any feedback you might have.
 
Thanks,
Matt Van Gundy
 
[1] http://www.cisco.com/en/US/docs/ios/preface/usingios.html
 
To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
mvg
Reply | Threaded
Open this post in threaded view
|

Re: Clarification of IOS schema line_object and global_object elements

mvg
In reply to this post by joval
Hi David,

On 1/10/12 6:40 PM, David Solin wrote:
> Currently, jOVAL implements the line_object by putting the entire output
> of the command into the config_line of a single line_item element, as
> there is nothing (like a line_number or instance element) that could be
> used to reassemble the output.  We don't yet implement the global_object.

Does jOVAL allow beginning and end of line anchors to match newlines
within the single config_line item?

> We're actually planning to complete our implementation of the entire IOS
> schema over the next few weeks, so I'd be very interested in hearing any
> thoughts or requirements you have about the individual tests.  Please
> feel free to contact me directly.

The commentary in this thread [1] seems to imply that global_test is
just a degenerate case of line_test (i.e.
<line_object><show_subcommand>show running-config</...).  And, Andrew
Buttner's comment that it might be deprecated in an upcoming OVAL
version in favor of line_test may make global_test's implementation a
moot point.  However, for the time being, I guess I'll assume that it is
just a degenerate case of line_test.

Thanks,
Matt

[1]
http://making-security-measurable.1364806.n2.nabble.com/Cisco-IOS-definitions-schema-Global-Test-Question-td1461415.html#a1486445

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
mvg
Reply | Threaded
Open this post in threaded view
|

Re: Clarification of IOS schema line_object and global_object elements

mvg
In reply to this post by Igor Prata
Hi Igor,

Forgive the redundancy, but I'm trying to determine if there's a
consensus on how line_test ought to be implemented.  Does modSIC allow
beginning and end of line anchors (^ and $) to match newlines within a
config_line?

Thanks,
Matt


On 1/17/12 3:31 PM, Igor Devulsky Prata wrote:

> Hello Matthew.
>
>  
>
> As jOVAL, modSIC implements the line_object catching the entire output
> of a command. Our OVAL Definitions test works with pattern match on
> those output.
>
> In our cases, we developed probes for line_object and Version55_object
> in Cisco iOS schema.
>
>  
>
>  
>
>  
>
>  
>
> Best Regards.
>
>  
>
>  
>
> _Igor Prata_
>
> modSIC Team - www.modsic.org <http://www.modsic.org/>
>
> Modulo Solutions for GRC - http://www.modulo.com <http://www.modulo.com/>
>
>  
>
>  
>
>  
>

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Clarification of IOS schema line_object and global_object elements

luciano
Hi Matthew,

I dont know if I understood your issue, but modSIC just sends the command to cisco device through a telnet connection and then gets the command output (with break lines) and put it in line_item in system characteristics.

For instance, If you want to catch a single line you must do that using pattern match operation in line state.

Anyway, I have attached a real system characteristics sample from our test environment.

Best Regards,

Luciano Fernandes
modSIC Team - www.modsic.org <http://www.modsic.org/>
Modulo Solutions for GRC - http://www.modulo.com <http://www.modulo.com/>


On Wed, Jan 18, 2012 at 2:11 PM, Matthew Van Gundy <[hidden email]> wrote:
Hi Igor,

Forgive the redundancy, but I'm trying to determine if there's a
consensus on how line_test ought to be implemented.  Does modSIC allow
beginning and end of line anchors (^ and $) to match newlines within a
config_line?

Thanks,
Matt


On 1/17/12 3:31 PM, Igor Devulsky Prata wrote:
> Hello Matthew.
>
>
>
> As jOVAL, modSIC implements the line_object catching the entire output
> of a command. Our OVAL Definitions test works with pattern match on
> those output.
>
> In our cases, we developed probes for line_object and Version55_object
> in Cisco iOS schema.
>
>
>
>
>
>
>
>
>
> Best Regards.
>
>
>
>
>
> _Igor Prata_
>
> modSIC Team - www.modsic.org <http://www.modsic.org/>
>
> Modulo Solutions for GRC - http://www.modulo.com <http://www.modulo.com/>
>
>
>
>
>
>
>

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

system-characteristics.xml (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Clarification of IOS schema line_object and global_object elements

joval
In reply to this post by mvg
Hi Matthew,

jOVAL will match the entire string (i.e., the results of the show command specified in the line_test, including newlines) with the pattern specified in the line_state.  I believe that ^ and $ would apply to that whole string, not to individual lines.

OVAL would need to add something like the Textfilecontent54Behaviors multiline attribute to support what you're looking for.  You could, however, include the newline character inside the pattern you're searching for, and that should have more or less the exact same effect.

Regards,
--DAS

On 1/18/2012 10:09 AM, Matthew Van Gundy wrote:
Hi David,

On 1/10/12 6:40 PM, David Solin wrote:
Currently, jOVAL implements the line_object by putting the entire output
of the command into the config_line of a single line_item element, as
there is nothing (like a line_number or instance element) that could be
used to reassemble the output.  We don't yet implement the global_object.
Does jOVAL allow beginning and end of line anchors to match newlines
within the single config_line item?

We're actually planning to complete our implementation of the entire IOS
schema over the next few weeks, so I'd be very interested in hearing any
thoughts or requirements you have about the individual tests.  Please
feel free to contact me directly.
The commentary in this thread [1] seems to imply that global_test is
just a degenerate case of line_test (i.e.
<line_object><show_subcommand>show running-config</...).  And, Andrew
Buttner's comment that it might be deprecated in an upcoming OVAL
version in favor of line_test may make global_test's implementation a
moot point.  However, for the time being, I guess I'll assume that it is
just a degenerate case of line_test.

Thanks,
Matt

[1]
http://making-security-measurable.1364806.n2.nabble.com/Cisco-IOS-definitions-schema-Global-Test-Question-td1461415.html#a1486445



--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|

Re: Clarification of IOS schema line_object and global_object elements

Luis Nunez
In reply to this post by luciano
This example should be good for the majority of the configuration checks but I am wonder if we need a new test to accommodate checks specific for: 
-VTY lines
-Network Interfaces
-routing instances


The number of Virtual Teletype Lines (telnet/ssh), Network ethernet/serial/token interfaces and enabled routing protocols can vary by IOS platforms (Routers/switches).

Side note: Would be nice to have a OVAL "Sandbox" for this. 

-ln


On Jan 18, 2012, at 12:23 PM, Luciano Castilho wrote:

Hi Matthew,

I dont know if I understood your issue, but modSIC just sends the command to cisco device through a telnet connection and then gets the command output (with break lines) and put it in line_item in system characteristics.

For instance, If you want to catch a single line you must do that using pattern match operation in line state.

Anyway, I have attached a real system characteristics sample from our test environment.

Best Regards,

Luciano Fernandes
modSIC Team - www.modsic.org <http://www.modsic.org/>
Modulo Solutions for GRC - http://www.modulo.com <http://www.modulo.com/>


On Wed, Jan 18, 2012 at 2:11 PM, Matthew Van Gundy <[hidden email]> wrote:
Hi Igor,

Forgive the redundancy, but I'm trying to determine if there's a
consensus on how line_test ought to be implemented.  Does modSIC allow
beginning and end of line anchors (^ and $) to match newlines within a
config_line?

Thanks,
Matt


On 1/17/12 3:31 PM, Igor Devulsky Prata wrote:
> Hello Matthew.
>
>
>
> As jOVAL, modSIC implements the line_object catching the entire output
> of a command. Our OVAL Definitions test works with pattern match on
> those output.
>
> In our cases, we developed probes for line_object and Version55_object
> in Cisco iOS schema.
>
>
>
>
>
>
>
>
>
> Best Regards.
>
>
>
>
>
> _Igor Prata_
>
> modSIC Team - www.modsic.org <http://www.modsic.org/>
>
> Modulo Solutions for GRC - http://www.modulo.com <http://www.modulo.com/>
>
>
>
>
>
>
>

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email]. <system-characteristics.xml>

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Clarification of IOS schema line_object and global_object elements

Igor Prata

Hello, Luis.

 

During the development of our probe for Cisco iOS we missed something better than the <interface_object>, as you said “network interfaces”. We only evaluated our tests over Cisco iOSs 11/12.

 

Side note: Would be nice to have a OVAL "Sandbox" for this. 

-          Yes, it will be a good way to start the sandbox.  J

 

 

Best Regards

Igor Prata

modSIC Team - www.modsic.org

Modulo Solutions for GRC - http://www.modulo.com

 

 

From: Luis Nunez [mailto:[hidden email]]
Sent: quarta-feira, 18 de janeiro de 2012 17:02
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Clarification of IOS schema line_object and global_object elements

 

This example should be good for the majority of the configuration checks but I am wonder if we need a new test to accommodate checks specific for: 

-VTY lines

-Network Interfaces

-routing instances

 

 

The number of Virtual Teletype Lines (telnet/ssh), Network ethernet/serial/token interfaces and enabled routing protocols can vary by IOS platforms (Routers/switches).

 

Side note: Would be nice to have a OVAL "Sandbox" for this. 

 

-ln

 

 

On Jan 18, 2012, at 12:23 PM, Luciano Castilho wrote:



Hi Matthew,

 

I dont know if I understood your issue, but modSIC just sends the command to cisco device through a telnet connection and then gets the command output (with break lines) and put it in line_item in system characteristics.

 

For instance, If you want to catch a single line you must do that using pattern match operation in line state.

 

Anyway, I have attached a real system characteristics sample from our test environment.

 

Best Regards,

 

Luciano Fernandes
modSIC Team - www.modsic.org <http://www.modsic.org/>
Modulo Solutions for GRC - http://www.modulo.com <http://www.modulo.com/>

 

On Wed, Jan 18, 2012 at 2:11 PM, Matthew Van Gundy <[hidden email]> wrote:

Hi Igor,

Forgive the redundancy, but I'm trying to determine if there's a
consensus on how line_test ought to be implemented.  Does modSIC allow
beginning and end of line anchors (^ and $) to match newlines within a
config_line?

Thanks,
Matt



On 1/17/12 3:31 PM, Igor Devulsky Prata wrote:
> Hello Matthew.
>
>
>
> As jOVAL, modSIC implements the line_object catching the entire output
> of a command. Our OVAL Definitions test works with pattern match on
> those output.
>
> In our cases, we developed probes for line_object and Version55_object
> in Cisco iOS schema.
>
>
>
>
>
>
>
>
>
> Best Regards.
>
>
>
>
>

> _Igor Prata_
>
> modSIC Team - www.modsic.org <http://www.modsic.org/>
>
> Modulo Solutions for GRC - http://www.modulo.com <http://www.modulo.com/>

>
>
>
>
>
>
>

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email]. <system-characteristics.xml>

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Clarification of IOS schema line_object and global_object elements

joval
In reply to this post by luciano
Hi Luciano,

I'm wondering, is there a reason modSIC indents the output inside the <config_line> element in the XML file?  That could make it difficult to precisely match a pattern.  An interpreter that consumed your system-characteristics file would likely assume the whitespace was part of the actual output.

The interface_object/test/item is (in my opinion) impenetrable, as it's completely devoid of any documentation.  Can anyone shed any light onto its meaning?

Regards,
--David Solin

On 1/18/2012 11:23 AM, Luciano Castilho wrote:
Hi Matthew,

I dont know if I understood your issue, but modSIC just sends the command to cisco device through a telnet connection and then gets the command output (with break lines) and put it in line_item in system characteristics.

For instance, If you want to catch a single line you must do that using pattern match operation in line state.

Anyway, I have attached a real system characteristics sample from our test environment.

Best Regards,

Luciano Fernandes
modSIC Team - www.modsic.org <http://www.modsic.org/>
Modulo Solutions for GRC - http://www.modulo.com <http://www.modulo.com/>


On Wed, Jan 18, 2012 at 2:11 PM, Matthew Van Gundy <[hidden email]> wrote:
Hi Igor,

Forgive the redundancy, but I'm trying to determine if there's a
consensus on how line_test ought to be implemented.  Does modSIC allow
beginning and end of line anchors (^ and $) to match newlines within a
config_line?

Thanks,
Matt


On 1/17/12 3:31 PM, Igor Devulsky Prata wrote:
> Hello Matthew.
>
>
>
> As jOVAL, modSIC implements the line_object catching the entire output
> of a command. Our OVAL Definitions test works with pattern match on
> those output.
>
> In our cases, we developed probes for line_object and Version55_object
> in Cisco iOS schema.
>
>
>
>
>
>
>
>
>
> Best Regards.
>
>
>
>
>
> _Igor Prata_
>
> modSIC Team - www.modsic.org <http://www.modsic.org/>
>
> Modulo Solutions for GRC - http://www.modulo.com <http://www.modulo.com/>
>
>
>
>
>
>
>

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].


--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|

Re: Clarification of IOS schema line_object and global_object elements

joval
Having just completed jOVAL's implementation of the IOS schema, I thought I should share the assumptions I have made with the community at large...

The results from show configuration or show running-config are a listing of IOS commands that can be used to replicate the device's configuration.  Some commands, like "interface ...", enter into a configuration mode to modify the named interface.

A global_object is supposed to represent a command made "in the global context".  I have interpreted this to mean that subcommands should be excluded.  For instance, an "interface..." command could be an item associated with a global_object, but a subcommand entered in the interface configuration mode like "duplex auto" could not.  jOVAL uses the running configuration to resolve all global items.

The interface_test is based upon interface subcommands found in "show running-config".  Only four subcommand types are collected by interface_item elements, and in my opinion they are not necessarily the most interesting ones, but at least it's an intelligible interpretation of this completely undocumented part of the schema.

The line_test appears, from the available examples, to be a way to gather the arbitrary results of any "show" command.  (Incidentally this makes all of the other tests pretty much redundant, with the exception of the tclsh_test.)  This test has already been discussed below.

An snmp_object refers to snmp commands in the running-config.  I interpret the community string as the name, and the access list number (1 to 99) as the access_list.

I think the tclsh_test and version55_test are both fairly well understood.

I'd be very interested in hearing whether anyone has a different interpretation of any of these tests!

Regards,
--David Solin

On 1/18/2012 8:57 PM, David Solin wrote:
Hi Luciano,

I'm wondering, is there a reason modSIC indents the output inside the <config_line> element in the XML file?  That could make it difficult to precisely match a pattern.  An interpreter that consumed your system-characteristics file would likely assume the whitespace was part of the actual output.

The interface_object/test/item is (in my opinion) impenetrable, as it's completely devoid of any documentation.  Can anyone shed any light onto its meaning?

Regards,
--David Solin

On 1/18/2012 11:23 AM, Luciano Castilho wrote:
Hi Matthew,

I dont know if I understood your issue, but modSIC just sends the command to cisco device through a telnet connection and then gets the command output (with break lines) and put it in line_item in system characteristics.

For instance, If you want to catch a single line you must do that using pattern match operation in line state.

Anyway, I have attached a real system characteristics sample from our test environment.

Best Regards,

Luciano Fernandes
modSIC Team - www.modsic.org <http://www.modsic.org/>
Modulo Solutions for GRC - http://www.modulo.com <http://www.modulo.com/>


On Wed, Jan 18, 2012 at 2:11 PM, Matthew Van Gundy <[hidden email]> wrote:
Hi Igor,

Forgive the redundancy, but I'm trying to determine if there's a
consensus on how line_test ought to be implemented.  Does modSIC allow
beginning and end of line anchors (^ and $) to match newlines within a
config_line?

Thanks,
Matt


On 1/17/12 3:31 PM, Igor Devulsky Prata wrote:
> Hello Matthew.
>
>
>
> As jOVAL, modSIC implements the line_object catching the entire output
> of a command. Our OVAL Definitions test works with pattern match on
> those output.
>
> In our cases, we developed probes for line_object and Version55_object
> in Cisco iOS schema.
>
>
>
>
>
>
>
>
>
> Best Regards.
>
>
>
>
>
> _Igor Prata_
>
> modSIC Team - www.modsic.org <http://www.modsic.org/>
>
> Modulo Solutions for GRC - http://www.modulo.com <http://www.modulo.com/>
>
>
>
>
>
>
>

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].


--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download



--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

mvg
Reply | Threaded
Open this post in threaded view
|

Re: Clarification of IOS schema line_object and global_object elements

mvg
Hi David,

On 1/19/12 2:18 PM, David Solin wrote:
> Having just completed jOVAL's implementation of the IOS schema, I
> thought I should share the assumptions I have made with the community at
> large...

Thank you for sharing a detailed analysis of your implementation
assumptions.  I'm interested in your (and anyone else's) thoughts on the
following.

> A global_object is supposed to represent a command made "in the global
> context".  I have interpreted this to mean that subcommands should be
> excluded.  For instance, an "interface..." command could be an item
> associated with a global_object, but a subcommand entered in the
> interface configuration mode like "duplex auto" could not.  jOVAL uses
> the running configuration to resolve all global items.

This sounds like a reasonable interpretation (as opposed to my
previously offered degenerate line_test interpretation).  Do you create
separate items for each line in the global context?  Or, do you create a
single item with all lines from the global context?

> The interface_test is based upon interface subcommands found in "show
> running-config".  Only four subcommand types are collected by
> interface_item elements, and in my opinion they are not necessarily the
> most interesting ones, but at least it's an intelligible interpretation
> of this completely undocumented part of the schema.

The lack of documentation of interface_test makes it particularly
opaque.  It looks to me like it might have been derived from the output
of "show ip interface" [1].  I'm curious how you implemented each of the
entities of interface_item.  Here's the behavior that I assumed. I'd
like to know what you think of it and where it may differ with your
interpretation.

- ip_directed_broadcast_command - entity is present only if
  "ip directed-broadcast" has been asserted on the interface.  The
  value of the entity is the access-list argument to the command
  (if any).

- no_ip_directed_broadcast_command - entity is present only if the
  "ip directed-broadcast" command has not been asserted on the
  interface.  The value is always empty because the argument cannot
  be determined reliably from "show running-config" or
  "show ip interface".

- proxy_arp_command - entity is always present.  Value is either
  "enabled" or "disabled" corresponding to the status of proxy arp
  on the interface.  See also: [2], [3]

- shutdown_command - entity is always present.  Suggested values might
  be yes/no or true/false indicating whether or not the shutdown
  command has been issued for the interface.  Using enabled/disabled
  might cause confusion over whether the interface is enabled or not.

> I think the tclsh_test and version55_test are both fairly well understood.

I think that the expected value of a version_string entity of a
version_item is a little vague.  Given that it can be of datatype
ios_version, which has operations such as "less than" defined over it, I
would expect it to be merely the version identifier (e.g. "12.4(9)T0a").
 This appears to be how it is used in definitions within the OVAL
repository.  However, this seems to be in conflict with the IOS
definitions schema's statement that it is "the raw string output of a
'show version' command".  The latter seems to indicate that the entire
output of show version should be included in this entity a la
config_line.  I'm inclined assume that the former interpretation is
incorrect given that line_test can be used to obtain the full output of
"show version".

Cheers,
Matt


[1]
http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr/command/ipaddr-r1.html#GUID-E8D74F04-67B7-43D7-9719-97F6092EE704

[2]
http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr/command/ipaddr-i4.html#GUID-AEB7DDCB-7B3D-4036-ACF0-0A0250F3002E

[3] http://www.cisco.com/en/US/docs/ios-xml/ios/ipswitch/command/isw-i1.html

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Clarification of IOS schema line_object and global_object elements

joval
Hi Matt,

Replies inline, below...

On 1/19/2012 5:38 PM, Matthew Van Gundy wrote:
A global_object is supposed to represent a command made "in the global
context".  I have interpreted this to mean that subcommands should be
excluded.  For instance, an "interface..." command could be an item
associated with a global_object, but a subcommand entered in the
interface configuration mode like "duplex auto" could not.  jOVAL uses
the running configuration to resolve all global items.
This sounds like a reasonable interpretation (as opposed to my
previously offered degenerate line_test interpretation).  Do you create
separate items for each line in the global context?  Or, do you create a
single item with all lines from the global context?

Unlike the line_test implementation, jOVAL creates a separate global_item for each global_object command.

The interface_test is based upon interface subcommands found in "show
running-config".  Only four subcommand types are collected by
interface_item elements, and in my opinion they are not necessarily the
most interesting ones, but at least it's an intelligible interpretation
of this completely undocumented part of the schema.
The lack of documentation of interface_test makes it particularly
opaque.  It looks to me like it might have been derived from the output
of "show ip interface" [1].  I'm curious how you implemented each of the
entities of interface_item.  Here's the behavior that I assumed. I'd
like to know what you think of it and where it may differ with your
interpretation.

- ip_directed_broadcast_command - entity is present only if
  "ip directed-broadcast" has been asserted on the interface.  The
  value of the entity is the access-list argument to the command
  (if any).
That's my interpretation as well.

- no_ip_directed_broadcast_command - entity is present only if the
  "ip directed-broadcast" command has not been asserted on the
  interface.  The value is always empty because the argument cannot
  be determined reliably from "show running-config" or
  "show ip interface".
Ditto, again.

- proxy_arp_command - entity is always present.  Value is either
  "enabled" or "disabled" corresponding to the status of proxy arp
  on the interface.  See also: [2], [3]
This is not always present in my interpretation.  Since the entity name is "proxy_arp_command", its value would be "ip proxy-arp" or "proxy-arp [enable|disable]" or "no proxy-arp", and only if such a command appears in the configuration of the particular named interface.

- shutdown_command - entity is always present.  Suggested values might
  be yes/no or true/false indicating whether or not the shutdown
  command has been issued for the interface.  Using enabled/disabled
  might cause confusion over whether the interface is enabled or not.
As with proxy_arp_command, this is only present if the command itself is present in the configuration.  Values are either "shutdown" or "no shutdown".

I think the tclsh_test and version55_test are both fairly well understood.
I think that the expected value of a version_string entity of a
version_item is a little vague.  Given that it can be of datatype
ios_version, which has operations such as "less than" defined over it, I
would expect it to be merely the version identifier (e.g. "12.4(9)T0a").
 This appears to be how it is used in definitions within the OVAL
repository.  However, this seems to be in conflict with the IOS
definitions schema's statement that it is "the raw string output of a
'show version' command".  The latter seems to indicate that the entire
output of show version should be included in this entity a la
config_line.  I'm inclined assume that the former interpretation is
incorrect given that line_test can be used to obtain the full output of
"show version".

It is rare that OVAL schema documentation is so straightforward, but you're right -- the schema definition clearly conflicts.  jOVAL provides the whole version identifier in that field (e.g., "12.3(8)JEA1").

Since jOVAL is an open-source project, you can of course read the "online documentation".  Here is where you can find the implementations of the IOS schema adapters:

https://github.com/joval/jOVAL/tree/master/src/org/joval/plugin/adapter/cisco/ios

Best regards,
--David Solin

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download