Passing variables to new and unexplored places...

[Vladimir Giszpenc]

Some javascript/style in this post has been disabled (why?)

Hi all,

 

Currently, the way to have an rpm_test test if a package exists and to allow either expected value (exists, does not exist) is to combine two different check_existence tests with corresponding variable checks.

 

            <ind-def:variable_test check_existence="all_exist"

id="some:tst:id1" version="1" check="all" comment="all_exist exist was specified">

                  <ind-def:object object_ref="some:obj:id1"/>

                  <ind-def:state state_ref="expected:ste:id1"/>

            </ind-def:variable_test>

            <lin-def:rpminfo_test check_existence="all_exist"

id="some:tst:id2" version="1" check="all" comment="The foo package should be installed or not as appropriate">

                  <lin-def:object object_ref="some:obj:id"/>

            </lin-def:rpminfo_test>

            <ind-def:variable_test check_existence="all_exist"

id="some:tst:id3" version="1" check="all" comment="none_exist exist was specified">

                  <ind-def:object object_ref="some:obj:id1"/>

                  <ind-def:state state_ref="some:ste:id2"/>

            </ind-def:variable_test>

            <lin-def:rpminfo_test check_existence="none_exist"

id="some:tst:id3" version="1" check="all" comment="The foo package should be installed or not as appropriate">

                  <lin-def:object object_ref="some:obj:id"/>

            </lin-def:rpminfo_test>

 

Could we somehow pass in the expected check_existence?

 

<lin-def:rpminfo_test check_existence="some:var:id" id="some:tst:id"

version="1" check="all" comment="Is the foo package installed?">

        <lin-def:object object_ref="some:obj:id"/> </lin-def:rpminfo_test>

 

 

This would reduce the weight of the OVAL significantly by removing tests and reducing the size of the criteria as well.  I realize that parameterized tests are a new thing and I am opening a bottle of worms, but it is worth getting on the table.  If we could make the data type of the variable somehow be restricted to valid check_existence values we would be set!

 

 

Regards,

 

Vladimir Giszpenc

DSCI Contractor Supporting

US Army CERDEC S&TCD IAD Tactical Network Protection Branch

[phone]

 

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

[bakerj]

Some javascript/style in this post has been disabled (why?)

Vlad,

 

I am not sure I understand the issue you are using as an example here. If I wanted to test if an rpm existed I would use a test like:

 

<lin-def:rpminfo_test check_existence="at_least_one_exists" id="some:tst:id3" version="1" check="all" comment="…">

     <lin-def:object object_ref="some:obj:id"/>

</lin-def:rpminfo_test>

 

This test will evaluate to true if at least one exists rpm is found that matches the criteria specified by the object. Now if I already have this test I could simply negate the criterion the refers to the test to give myself a criterion that would evaluate to true if no rpms are found that match the criteria specified by the object.

 

Is this what you are looking for?

 

Can you help me understand the issue?

 

Jon

 

============================================

Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]

 

From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Monday, July 13, 2009 2:53 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] Passing variables to new and unexplored places...

 

Hi all,

 

Currently, the way to have an rpm_test test if a package exists and to allow either expected value (exists, does not exist) is to combine two different check_existence tests with corresponding variable checks.

 

            <ind-def:variable_test check_existence="all_exist"

id="some:tst:id1" version="1" check="all" comment="all_exist exist was specified">

                  <ind-def:object object_ref="some:obj:id1"/>

                  <ind-def:state state_ref="expected:ste:id1"/>

            </ind-def:variable_test>

            <lin-def:rpminfo_test check_existence="all_exist"

id="some:tst:id2" version="1" check="all" comment="The foo package should be installed or not as appropriate">

                  <lin-def:object object_ref="some:obj:id"/>

            </lin-def:rpminfo_test>

            <ind-def:variable_test check_existence="all_exist"

id="some:tst:id3" version="1" check="all" comment="none_exist exist was specified">

                  <ind-def:object object_ref="some:obj:id1"/>

                  <ind-def:state state_ref="some:ste:id2"/>

            </ind-def:variable_test>

            <lin-def:rpminfo_test check_existence="none_exist"

id="some:tst:id3" version="1" check="all" comment="The foo package should be installed or not as appropriate">

                  <lin-def:object object_ref="some:obj:id"/>

            </lin-def:rpminfo_test>

 

Could we somehow pass in the expected check_existence?

 

<lin-def:rpminfo_test check_existence="some:var:id" id="some:tst:id"

version="1" check="all" comment="Is the foo package installed?">

        <lin-def:object object_ref="some:obj:id"/> </lin-def:rpminfo_test>

 

 

This would reduce the weight of the OVAL significantly by removing tests and reducing the size of the criteria as well.  I realize that parameterized tests are a new thing and I am opening a bottle of worms, but it is worth getting on the table.  If we could make the data type of the variable somehow be restricted to valid check_existence values we would be set!

 

 

Regards,

 

Vladimir Giszpenc

DSCI Contractor Supporting

US Army CERDEC S&TCD IAD Tactical Network Protection Branch

[phone]

 

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

[Vladimir Giszpenc]

Some javascript/style in this post has been disabled (why?)

Jon,

 

If you have two possible variable values in XCCDF with “enabled” and “disabled” translating to a variable check on the OVAL side comparing XCCDF external variable values to different expected states per test, you get a definition that checks for

 

If expected state is enabled and test for at least one exists

OR

If expected state is disabled and test for none exists.

 

I agree that this could be rewritten with expected state is disabled and test not at least one exists.  If one of the possible expected states is all exists though, it can get tricky.  So my question was about passing in the expected check_existence from XCCDF to reduce the OVAL needed to express tailorable content.

 

 

Thanks,

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
[phone]

From: Baker, Jon [mailto:[hidden email]]
Sent: Thursday, July 30, 2009 12:50 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Passing variables to new and unexplored places...

 

Vlad,

 

I am not sure I understand the issue you are using as an example here. If I wanted to test if an rpm existed I would use a test like:

 

<lin-def:rpminfo_test check_existence="at_least_one_exists" id="some:tst:id3" version="1" check="all" comment="…">

     <lin-def:object object_ref="some:obj:id"/>

</lin-def:rpminfo_test>

 

This test will evaluate to true if at least one exists rpm is found that matches the criteria specified by the object. Now if I already have this test I could simply negate the criterion the refers to the test to give myself a criterion that would evaluate to true if no rpms are found that match the criteria specified by the object.

 

Is this what you are looking for?

 

Can you help me understand the issue?

 

Jon

 

============================================

Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]

 

From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Monday, July 13, 2009 2:53 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] Passing variables to new and unexplored places...

 

Hi all,

 

Currently, the way to have an rpm_test test if a package exists and to allow either expected value (exists, does not exist) is to combine two different check_existence tests with corresponding variable checks.

 

            <ind-def:variable_test check_existence="all_exist"

id="some:tst:id1" version="1" check="all" comment="all_exist exist was specified">

                  <ind-def:object object_ref="some:obj:id1"/>

                  <ind-def:state state_ref="expected:ste:id1"/>

            </ind-def:variable_test>

            <lin-def:rpminfo_test check_existence="all_exist"

id="some:tst:id2" version="1" check="all" comment="The foo package should be installed or not as appropriate">

                  <lin-def:object object_ref="some:obj:id"/>

            </lin-def:rpminfo_test>

            <ind-def:variable_test check_existence="all_exist"

id="some:tst:id3" version="1" check="all" comment="none_exist exist was specified">

                  <ind-def:object object_ref="some:obj:id1"/>

                  <ind-def:state state_ref="some:ste:id2"/>

            </ind-def:variable_test>

            <lin-def:rpminfo_test check_existence="none_exist"

id="some:tst:id3" version="1" check="all" comment="The foo package should be installed or not as appropriate">

                  <lin-def:object object_ref="some:obj:id"/>

            </lin-def:rpminfo_test>

 

Could we somehow pass in the expected check_existence?

 

<lin-def:rpminfo_test check_existence="some:var:id" id="some:tst:id"

version="1" check="all" comment="Is the foo package installed?">

        <lin-def:object object_ref="some:obj:id"/> </lin-def:rpminfo_test>

 

 

This would reduce the weight of the OVAL significantly by removing tests and reducing the size of the criteria as well.  I realize that parameterized tests are a new thing and I am opening a bottle of worms, but it is worth getting on the table.  If we could make the data type of the variable somehow be restricted to valid check_existence values we would be set!

 

 

Regards,

 

Vladimir Giszpenc

DSCI Contractor Supporting

US Army CERDEC S&TCD IAD Tactical Network Protection Branch

[phone]

 

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

[bakerj]

Some javascript/style in this post has been disabled (why?)

Ok, I think I understand the idea here. I can see the benefit in terms of simplifying the oval content. However, this change would likely make evaluating oval content a bit more complicated and may reduce the readability of oval content. This is a tradeoff we should be aware of. This is something that we could investigate for a future release.

 

Jon

 

============================================

Jonathan O. Baker

G022 - IA Industry Collaboration

The MITRE Corporation

Mobile: [phone]

Office: (781)-271-8357

Email: [hidden email]

 

From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Thursday, July 30, 2009 1:38 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] Passing variables to new and unexplored places...

 

Jon,

 

If you have two possible variable values in XCCDF with “enabled” and “disabled” translating to a variable check on the OVAL side comparing XCCDF external variable values to different expected states per test, you get a definition that checks for

 

If expected state is enabled and test for at least one exists

OR

If expected state is disabled and test for none exists.

 

I agree that this could be rewritten with expected state is disabled and test not at least one exists.  If one of the possible expected states is all exists though, it can get tricky.  So my question was about passing in the expected check_existence from XCCDF to reduce the OVAL needed to express tailorable content.

 

 

Thanks,

Vladimir Giszpenc
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
[phone]

From: Baker, Jon [mailto:[hidden email]]
Sent: Thursday, July 30, 2009 12:50 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Passing variables to new and unexplored places...

 

Vlad,

 

I am not sure I understand the issue you are using as an example here. If I wanted to test if an rpm existed I would use a test like:

 

<lin-def:rpminfo_test check_existence="at_least_one_exists" id="some:tst:id3" version="1" check="all" comment="…">

     <lin-def:object object_ref="some:obj:id"/>

</lin-def:rpminfo_test>

 

This test will evaluate to true if at least one exists rpm is found that matches the criteria specified by the object. Now if I already have this test I could simply negate the criterion the refers to the test to give myself a criterion that would evaluate to true if no rpms are found that match the criteria specified by the object.

 

Is this what you are looking for?

 

Can you help me understand the issue?

 

Jon

 

============================================

Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]

 

From: Vladimir Giszpenc [mailto:[hidden email]]
Sent: Monday, July 13, 2009 2:53 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] Passing variables to new and unexplored places...

 

Hi all,

 

Currently, the way to have an rpm_test test if a package exists and to allow either expected value (exists, does not exist) is to combine two different check_existence tests with corresponding variable checks.

 

            <ind-def:variable_test check_existence="all_exist"

id="some:tst:id1" version="1" check="all" comment="all_exist exist was specified">

                  <ind-def:object object_ref="some:obj:id1"/>

                  <ind-def:state state_ref="expected:ste:id1"/>

            </ind-def:variable_test>

            <lin-def:rpminfo_test check_existence="all_exist"

id="some:tst:id2" version="1" check="all" comment="The foo package should be installed or not as appropriate">

                  <lin-def:object object_ref="some:obj:id"/>

            </lin-def:rpminfo_test>

            <ind-def:variable_test check_existence="all_exist"

id="some:tst:id3" version="1" check="all" comment="none_exist exist was specified">

                  <ind-def:object object_ref="some:obj:id1"/>

                  <ind-def:state state_ref="some:ste:id2"/>

            </ind-def:variable_test>

            <lin-def:rpminfo_test check_existence="none_exist"

id="some:tst:id3" version="1" check="all" comment="The foo package should be installed or not as appropriate">

                  <lin-def:object object_ref="some:obj:id"/>

            </lin-def:rpminfo_test>

 

Could we somehow pass in the expected check_existence?

 

<lin-def:rpminfo_test check_existence="some:var:id" id="some:tst:id"

version="1" check="all" comment="Is the foo package installed?">

        <lin-def:object object_ref="some:obj:id"/> </lin-def:rpminfo_test>

 

 

This would reduce the weight of the OVAL significantly by removing tests and reducing the size of the criteria as well.  I realize that parameterized tests are a new thing and I am opening a bottle of worms, but it is worth getting on the table.  If we could make the data type of the variable somehow be restricted to valid check_existence values we would be set!

 

 

Regards,

 

Vladimir Giszpenc

DSCI Contractor Supporting

US Army CERDEC S&TCD IAD Tactical Network Protection Branch

[phone]

 

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

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